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. > >>>>> <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? > Gnome-bluez, which is maintained by Marcel, is GUI for BlueZ. We could use it for development purpose. The bluetooth GUI in Moblin is owned by Guru team. I don't know much about the current status. >> 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? OK, I understand the meaning of this parameter. No need to rename it. 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? 2 where can I find a peer (i.e. OBEX client/SyncML server) to debug to-be-developed obexd plugin for SyncEvolution client? Thanks, Forrest _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
