Hi, On Mon, May 29, 2006 at 11:54:42PM +0400, Alex Kanavin wrote: > On Fri, 26 May 2006, Christian W. Zuckschwerdt wrote: > > >URIs are not a concern of OpenOBEX. To users on the other hand it is not > >viable to present raw structs (i.e. obex_interface_t) least let them > >interact with those. So all programs using OpenOBEX (e.g. ObexFTP) would > >need to translate these both ways. Output some friendly results when > >discovering devices and let the user select from these (input ). > >I some cases this can be done transparently (e.g. with dialog options in > >guis). In the general case however a collapsed representation in a single > >character string is needed. > > I think that friendly results are human-readable descriptions of the > interfaces. For Bluetooth this could be device name and service name/class > name. Ditto for USB. This is totally trivial to get from the interface > structures, but impossible to get from URI strings. Also, if the program > wants to only use a specific class of interfaces, you're forcing them to > parse the URI into bits - going back to the raw structs.
However, I also think that having a way to represent the information about the services in a URI will be useful for applications that need to exchange or store the identification of a given device/service. One example of these cases is the Synchronization configuratin of OpenSync, another example are URLs that could be used by KDE to provide access to obex services (for example, the already-existing obex:// KIO slave. It doesn't seem to support USB yet, but it may profit from a defined URI scheme that would work with USB also). One may argue that device-name/class-name pairs or other information are enough to locate a device or service, but the usage of URIs has the same advantage of the usage of URIs for http, for example. It is easier for people (and for programs communicating) just say "go to http://example.com/a/b/c?x=1";, instead of saying: """ Connect via HTTP to: Server: example.com Path: /a/b/c Parameters: x=1 """ It is similar for programs exchaning information about obex services. Using URIs, programs don't need to know in advance what parameters are needed for every possible transport. For example: for bluetooth and usb people may use device-name and service/class name, but for other transports, we don't know which parameters may be needed. If they just store a plain URI, they may simply use it to connect to the service, without needing to know which information is contained in it. > > >This is also much more convenient for the language bindings in ObexFTP (I > >don't want to expose all the fussy details from FindInterface e.g.). There > >are six bindings in need of this already. > > Again, you have to expose e.g. the USB or Bluetooth device name because > the users of the programs that use the bindings want to know that. I don't > see how that could be put into an URI, and providing separate API calls > makes the URI pointless. I agree with this point. However I still think that having a defined URI scheme will be useful. I don't argue that this is supposed to be included in openobex, but having an URI scheme defined (and possibly implemented either on openobex or as some helper functions) would be interesting. > > >To get to the point: this is something I want to do (in ObexFTP). And I > >hope to get some comments on a 'best URI scheme'. > > Drop the idea, it's not worth it :) I disagree. :) -- Eduardo
pgpZbPU99tTp5.pgp
Description: PGP signature
