8:50 a.m.
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.
> <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?
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?
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.
> <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/copyrigh....
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
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.
--
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.