On Mon, 2009-10-19 at 10:09 +0100, Zhao, Forrest wrote:
> Can you add more information? The following keys are currently
> "description" - a description of the peer in a format and
> language that is understood by the user.
> You are sending "obexd stub", but we need something about the remote
> OBEX peer, like the device description (whatever is available - I
> don't know).
In updated version I keep "description" as "obexd stub". I could set
"description" the same as "id" (i.e. BT MAC address + channel
to identify the remote OBEX peer if you like.
If you can't get device information about the peer, then please leave
out "description" entirely. If we use the "description" as specified
(string which is visible to users), then both "obexd stub" and MAC
address would be confusing.
This doesn't solve the problem of GUI integration, but we can defer that
> "id" - a unique ID for this particular
peer, in a format
> that is specific to the transport. The ID only has to be
> unique among peers using that transport at the current
> point in time.
"id" is set to BT MAC address + channel number, which could identify the remote
OBEX peer uniquely.
I was about to ask about the format when I saw you example below. Can we
make it slightly more machine readable, perhaps like this?
> For OBEX over Bluetooth we need the MAC address. From what Lukas
> us about his experience with SAN as used by e.g. Nokia's PC Suite, the
> server doesn't put something unique into the SAN message itself. The
> client is supposed to identify the server via the connection's meta
> "transport_description" - could be used to describe the
> version of the transport entity.
> Can you add an obexd version number?
obexd version number is added.
Please put it into "transport_description", not "transport". While we
are at it, perhaps append "obexd" to ensure that we don't get conflicts
later on; "org.openobex" could host multiple programs talking to
=> "transport" = "org.openobex.obexd"
"transport_description" = "version 0.18"
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.