Re: [openobex-users] Re: OpenOBEX USB homepage, new obexftp beta

[Christian W. Z. <Christian@Zuckschwerdt.org>]

Hi,

Alex Kanavin wrote:

> The actual ids, addresses and numbers are hidden in intf_ pointers, 
> which the application doesn't need to access.
> Devices and interfaces have readable names (e.g. "Nokia 7610" and 
> "OBEX Object Push") and there's also capability information, so you 
> can either present a list of those triplets to the user, or have an 
> application choose the one it wants automatically. Where's the icky 
> bit here?


Seems we are talking the same language after all ;) So if a user 
requests connection to his 7610 or some Nokia and the application knows 
it wants Obex FT, all it has to do is get the array, look up the right 
pair (i.e. "*7610" or "Nokia*" with Obex FT) and voila.

I can't think of any other way an application would choose the 
connection. So hide the _intf parts inside the lib. If the pair/triplet 
is ambiguous there is nothing the application could possibly do about 
it. That's my point here. The application won't choose a specific 
interface/configuration, bus or dev. If it can't identify the connection 
based on device name and service type it simply has to enumerate and 
probe all candidates.

Now, is there a way to join the interface name and capabilities into a 
single field? If I take a look at the SDP fields (sorry I don't have a 
USB capable phone) it seems the interface name is descriptional only.
We should stick to the capabilities (SDP has Service Class IDs and 
Profile Descriptors for this -- e.g.
0x1105 for "OBEX Object Push")

The application would then filter the connection list by "Nokia 7610" 
and 0x1105 and use an opaque identifier (i.e. hidden _intf structure) to 
connect.

> On the other hand, probing for IMEI, which has nothing to do with OBEX 
> and may or may not be present, definitely doesn't belong in a generic 
> obex protocol library.


You are right. I didn't meant to imply that. Its mostly the scope of 
obexftp, e.g.


cu,
Christian