On Thu, 2009-08-06 at 03:47 +0100, Zhao, Forrest wrote:
Ohly, Patrick wrote:
> On Wed, 2009-08-05 at 10:11 +0100, Zhao, Forrest wrote:
>> Ohly, Patrick wrote:
>>> On Wed, 2009-08-05 at 09:20 +0100, Zhao, Forrest wrote:
>>>>> <arg type="s" name="peer_description"
>>>>> <doc:doc> <doc:summary>
>>>>> A description of the peer in a format and language
>>>>> that is understood by the user.
>>>> Take OBEX server/SyncML client binding for example, what name is
>>>> appropriate for "peer_description"?
>>> Do you have access to device information in obexd? Using the device
>>> name would be suitable, or the brand + model.
>> Local device information or remote device information? Do you mean
>> the bluetooth adapter device information?
> Remote. The local Bluetooth adapter information are of not much use
> for the user. They might be useful for debugging, though. Should we
> add a "transport_description" argument for that purpose?
Now I understand the meaning of "peer_description". Let's add
"transport_description" argument if necessary in the future.
Is it possible to add parameters to a D-Bus interface without breaking
compatibility? Doesn't seem like this is possible, so I'd rather add the
Now I think I understand the requriement for OBEX
server/SyncEvolution client binding.
Then I have 2 questions:
1 when can I expect to have the SyncEvolution client, which implement the proposed
Just the interface, without real functionality behind it: end of next week
Fully implemented: two weeks from now
This is an aggressive schedule, with a certain risk of delays. If you
don't need it that early (for example, if you cannot start working on it
now anyway), then we should go for a less risky schedule.
What do you think is a realistic schedule for adding the obexd plugin?
Can we count on you to do it? I assume we can, but I wanted to give you
a chance to say "no" ;-)
2 where can I find a peer (i.e. OBEX client/SyncML server) to debug
obexd plugin for SyncEvolution client?
It comes with a rudimentary syncml-ds-tool which does SyncML via OBEX,
without implementing any of the advanced SyncML logic. This should be
good enough to verify that connections can be established and (once that
works in obexd) to test SyncEvolution as OBEX server/SyncML client.
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.