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? > >>> <arg type="s" name="peer_id" direction="in"> >>> <doc:doc> >>> <doc:summary> >>> 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. </doc:summary> >>> </doc:doc> >>> </arg> >>> <arg type="s" name="transport" direction="in"> >>> <doc:doc> <doc:summary> >>> A string identifying the entity which talks directly >>> to SyncEvolution (peer or transport stub). If available, >>> this should be a D-Bus interface name. The main purpose >>> right now is for informing the user and debugging. >>> Later it might also be used to call methods in that >>> interface or for choosing a local configuration for >>> the peer based on its ID. >>> </doc:summary> >>> </doc:doc> >>> </arg> >> >> Is it appropriate to set "transport" to "OBEX" in obexd plugin? > > I think org.openobex would be better (there might be different OBEX > transports). > >>> <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). But here I think we are talking about the SynML-level authentication, right? Does SyncML spec define the authentication mechanism? > > As a different example, it should be true for a HTTP server, unless > the server requires HTTP AUTH. > >>> <arg type="u" name="session" direction="in"> >>> <doc:doc> >>> <doc:summary> >>> If this is a reconnect for an older session, >>> then pass the session number here. Otherwise >>> pass 0. New session numbers are created in >>> response to the initial message. >>> </doc:summary> >>> </doc:doc> >>> </arg> >> >> For OBEX session is always 0 since OBEX has no mechanism to support >> reconnection. > > Correct. > >>> <arg type="ay" name="message" direction="in"> >>> <doc:doc> <doc:summary> >>> The data to be processed. Empty messages are invalid >>> and will trigger an error. >>> </doc:summary> >>> </doc:doc> >>> </arg> >>> >> >> 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. > > 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(). > >>> <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? I ask this because there's a "final" out parameter for process(). > > If the OBEX client does not send a GET at all, then it is buggy. This > needs to be detected by a timeout inside SyncEvolution, just like any > other "unresponsive peer" situation. obexd can keep the response > around until either it is delivered or the connection is aborted. > > OBEX is somewhat special in that it doesn't allow the transport to > push the response. Exposing this in the API would make it > unnecessarily complex for other cases where the response can be > pushed, so if possible, I'd like to hide this PUT/GET semantic inside > obexd. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
