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" direction="in"> > >>>>> <doc:doc> <doc:summary> > >>>>> A description of the peer in a format and language > >>>>> that is understood by the user. > >>>>> </doc:summary> > >>>>> </doc:doc> > >>>>> </arg> > >>>> > >>>> 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 parameter now. > 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 > D-Bus API? 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 > to-be-developed > obexd plugin for SyncEvolution client? libsyncml: https://libsyncml.opensync.org/ https://libsyncml.opensync.org/wiki/obex-guide 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
