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? > >>> <arg type="b" name="must_authenticate" direction="in"> > >>> <doc:doc> <doc:summary> > >>> If false, then the peer is trusted and shall be given > >>> access to SyncEvolution without further checks by > >>> SyncEvolution itself. This is useful for peers which > >>> already run as local user processes with same access > >>> rights to the data as SyncEvolution or for transports > >>> that authenticate and authorize access via their own > >>> mechanisms. > >>> > >>> If true, then a SyncML client peer must provide valid > >>> credentials as part of the SyncML session. For a server, > >>> a valid configuration must exist. SyncEvolution searches > >>> for such a configuration by matching the sync URL in > >>> the Notification with sync URLs in the configurations. > >>> </doc:summary> </doc:doc> > >>> </arg> > >> > >> How should obexd plugin know if the SyncML-level authentication is > >> needed? > > > > The peer must have paired before it is allowed to ask for an OBEX > > connection. As a first approximation I'd say that this is enough to > > ensure that the peer is authenticated already, so use > > must_authenticate=false in all cases. > > > > This is rather crude because it does not take into account why the > > user has allowed pairing, but as far as I know, this "all or nothing" > > approach is what is commonly used with Bluetooth, isn't it? > > No, besides the pairing process there's an authentication mechanism > for each bluetooth profile (e.g PBAP, FTP, OPP). Ah, I see. Then we should require that the pairing process has authorized access to SyncML before calling connect(). must_authorize would still be false. Do we have a GUI for this pairing process in Moblin or in Linux desktops in general? > But here I think we are talking about the SynML-level authentication, right? > Does SyncML spec > define the authentication mechanism? Yes, there is a username/password mechanism. Using it in the context of Bluetooth would not be very user-friendly though or might not work at all (no credentials to check against on a phone). > >> If the message is too long, OBEX would split the message into muliple > >> packets and send them seperately. It would be nice for SyncEvolution > >> to provide a API to transmit multiple packets belonging to one > >> message. > > > > I was arguing with myself about that. I agree that it would be nice, > > but is it really worth making the API more complex? How long is "too > > long" in the context of OBEX? > > Library openobex send message in unit of 1500 bytes. My guess is that sending data in such small chunks over D-Bus would lead to too many messages and performance problems (untested). > > I think that with a small enough maximum message size (64KB? more? > > less?) we can safely buffer a complete message inside obexd before > > sending it over D-Bus and then wouldn't have to change the API. > > OK, anyway I don't think it a good idea to cache packets, but obexd > could buffer a complete message and call process(). Yes, let's do that. We can tweak the size of messages that have to buffered and send over D-Bus once we have something working. > >>> <arg type="ay" name="reply" direction="out"> > >>> <doc:doc> > >>> <doc:summary> > >>> The data to be returned to the peer. An empty reply is > >>> possible as response to the last message; it must not be > >>> delivered. Instead, final will be true and the > >>> connection needs to be closed. > >>> </doc:summary> > >>> </doc:doc> > >>> </arg> > >>> > >> I'm afraid this way of returning data does not work. Please read > >> section 6.2 > >> of > >> http://www.openmobilealliance.org/Technical/release_program/docs/copyrightclick.aspx?pck=DS&file=V2_0-20090212-C/OMA-TS-SyncML_OBEXBinding-V1_2-20070221-A.pdf. > >> OBEX client first send SyncML request to OBEX server by PUT command; > >> then OBEX server can't return data to OBEX client actively. OBEX > >> client has to send GET command to pull results. > > > > I had a question mark behind GET in one of my earlier emails because I > > wasn't sure how the GET works. > > > > The D-Bus API would still work as-is: > > - OBEX client sends PUT, triggering an asynchronous process() call > > - OBEX client sends GET, gets blocked because no data is available yet > > - process() returns the response > > - response is delivered to client via the pending GET > > Then I have another question: after async D-Bus process() call, can > SyncEvolution return multiple results? No. There's exactly one response for each incoming message. > I ask this because there's a "final" out parameter for process(). That signals end-of-connection, not "final response for this message". Should I rename the parameter? -- 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
