Re: [SyncEvolution] git status update + obexd update
On Fri, 2009-10-16 at 02:21 +0100, Zhao, Forrest wrote:
Ohly, Patrick wrote:
> On Thu, 2009-10-15 at 09:36 +0100, Zhao, Forrest wrote:
>> Thank you for update. Congwu has helped me to update to the right git
>> branch of syncevolution and libsynthesis yesterday. My status is: the
>> code for OBEX server/SyncML client binding is done; now I'm doing
>> unit testing. Will send out the patch to obexd mailing list for
>> review soon (in about 1 -2 days).
>
> Excellent. Can you post an example "dbus-monitor" dump of the initial
> org.syncevolution.Server.Connect() call? I'd like to have a look at
> what information is available to SyncEvolution when it is contacted
> by obexd.
>
I attached the "dbus-monitor" dump of org.syncevolution.Server.Connect() call.
FYI.
method call sender=:1.344 -> dest=org.syncevolution
path=/org/syncevolution/Server; interface=org.syncevolution.Server;
member=Connect
array [
dict entry(
string "description"
string "obexd stub"
)
dict entry(
string "transport"
string "org.openobex"
)
]
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).
"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.
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?
--
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.