Hi Alex,
thanks for your feedback. Well lets get more ObexFTP specific. There are
multiple bits of information the user specifies to select a device.
Whether its on the command line or as arguments to some function doesn't
matter. Protocol, service, transport are common (protocol and service
are implied to be obex/ftp) and then transport specific parameters.
Mostly device and port/channel. There are sane defaults and most are
optional. It works.
The effort now is to piece everything together into a URI string
representation. Joining host and port by a colon ':' is common practice.
Now we need to glue the other bits.
The main problem here is that we have three, maybe two, orthogonal
selectors and as far as I can see URI schemes allow only for one
selector (the protocol, e.g. http, here obex). From there on one can
only suffix sub-selectors (e.g. urn:oasis:names:specification:docbook).
And to me the transport is not related to the protocol (or vice versa).
In the limited context of ObexFTP we could get away with
transport://host:port/path/file. I really don't like the idea that obex
and ftp are implied.
We shouldn't use the service uuid as pseudo port number. I can see
problems right away.
The main point here being: How should protocol, service and transport be
folded, joined or wrapped?
One last thing. The user would perhaps want to outright omit the
host:port part of the URI to catch 'just one' device. E.g. there is most
likely one device in IrDA range.
Alex Kanavin wrote:
I think that friendly results are human-readable descriptions of the
interfaces.
Right, GUIs would only need to show the interesting/differing bits.
("found two devices. do you want the usb or the irda one?")
I'm talking about some kind of 'external' representation which would be
'portable'. (Nobody is intrigued to use urls for her filesystem. On the
net thats mandatory though.)
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.
Interesting point, we need one 'normalized' output (e.g. the MAC for BT)
and multiple input schemes (e.g. the BT nickname).
and providing separate API calls makes the URI pointless.
Quite contrary. There will be an generic API to manipulate URIs. Like
the java.net.URL class.
Drop the idea, it's not worth it :)
C'mon don't spoil the fun! :)
cu,
Christian
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Openobex-users mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/openobex-users
