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"
>>> <doc:doc> <doc:summary>
>>> A description of the peer in a format and language that
>>> is understood by the user.
>> 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
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"
>>> <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
>>> 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>
>> How should obexd plugin know if the SyncML-level authentication is
> 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
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
>> packets and send them seperately. It would be nice for SyncEvolution
>> to provide a API to transmit multiple packets belonging to one
> 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?
> 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"
>>> 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.
>> I'm afraid this way of returning data does not work. Please read
>> section 6.2
>> 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
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.