>
> Can you add more information? The following keys are currently
> defined:
>
> "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 number) to
identify the remote OBEX peer if you like.
>
> "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.
> For OBEX over Bluetooth we need the MAC address. From what Lukas told
> 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
> information.
>
> "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. The below is dump of dbus-monitor:
method call sender=:1.357 -> dest=org.syncevolution
path=/org/syncevolution/Server; interface=org.syncevolution.Server;
member=Connect
array [
dict entry(
string "description"
string "obexd stub"
)
dict entry(
string "id"
string "00:0A:94:03:EB:E5, channel 16"
)
dict entry(
string "transport"
string "org.openobex, version 0.18"
)
]
boolean false
string ""
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
