On Fri, 22 Jul 2005, Hendrik Sattler wrote:
> However, you do something strange, too:
> obex_return_val_if_fail(interface != NULL, -1);
> in function
> int UsbOBEX_TransportConnect(obex_t *self, struct usb_obex_intf* interface)
> You fail without looking for already scanned devices. I'd rather suggest that
> if interface == NULL, take the first one from the list and only fail if the
> list ist empty. This would make is easier for an application author.
Er, no. There can be many USB OBEX interfaces on one device (all Nokia
phones I know have two - one for SyncML, another for filetransfers), and
the library should not guess which one the application wants.
Similarly, Nokias have no less than four Bluetooth OBEX interfaces
(Object Push, File Transfer, SyncML and PC Suite Services, which is
apparently same as filetransfer, only giving access to the whole phone's
filesystem - plain filetransfer only provides access to the inbox folder
on the phone), so you can't just pick the first one.
> Still, UsbOBEX_GetInterfaces() is exactly what I meant. Somthing that can be
> extended to bluetooth and IrDA. I'd do it if noone else wants (the code is
> extually already there), if the openobex author actually thinks that this is
> the right direction.
You need to provide some information about the discovered interfaces, so
that the applications can pick the one they want. For Bluetooth I think
device, address, port, service class list, profile descriptor list and
service name string are good enough.
> Why doing all this? My wishlist includes obexftp being able to scan for and
> list all possible devices like "obexftp -F" listing IrDA, bluetooth and USB
> devices (serial is not detectable) in _one_ command.
Splitting interface scans by transport type (obexftp -b, obexftp -U) is
quite fine I think. I'll write a patch that adds USB scanning to obexftp,
it's really easy.
>> That would be really useful I think. The tricky part is how to unite all
>> possible transports in one structure - discovery has to return useful
>> iinformation about discovered interfaces to use in UI frontends and that
>> varies greatly from transport to transport. USB OBEX discovery already
>> provides that.
> I did not mean the unification of those function. Currently, openobex scans
> for the first IrDA device with OBEX support and not at all for bluetooth. The
> program cannot use this scan functionality to choose a device (except for
I had a look and apparently what happens with irda is that you can either
supply an address yourself when making a connect request, or, if you don't
do that, the library would do a proximity scan and pick the last device on
the list. Which I think isn't clever at all. What if there are several
devices around? What if a device has several OBEX services (not sure if
it's possible with infrared, but anyway)?