Hi, Slawek, On Wed, Nov 16, 2011, Slawomir Bochenski wrote: > The function itself is quite useful for MAP clients. There is this > fixed part of directories structure in MAP, which is: > > telecom > '- msg > |- inbox > |- outbox > |- sent > |- deleted > '- draft > > There are no messages in msg, thus going from e.g. outbox to sent > directly seems convenient. > > I do not understand why you are so reluctant to have function for > setting path in gobex that actually offers what OBEX offers. As I > mentioned already in discussion about MAP API proposal, this also > gives additional restrictions on what characters one can use in folder > name. > > You at least have one example of profile that could have make use of > it. So it won't be in effect anything that is not used. I don't as such have anything against the possibility of supporting a "cd ../foo" operation through the API, but the way that the OBEX spec implements it feels like a hack that's been put in place as an afterthought (they thought they'd get away with restricting path changes to one level at a time and when they realized ../foo might make sense instead of extending the name header they added this to flags (I don't know if this is how things actually happened but it's the impression I get). In OBEX 1.4 the DestName header was defined to tackle this shortcoming of the Name header, but at that point it was too late to have SetPath use it due to backwards compatibility reasons. Anyway, there's no reason to expose this ugliness in our APIs and we can still support the feature by allowing the application to pass "../foo" as the path name. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
