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"
>>>> <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 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"
>>>> <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>
>>> 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 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"
>>>> 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 of
>>> 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
>> - 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
2 where can I find a peer (i.e. OBEX client/SyncML server) to debug to-be-developed
obexd plugin for SyncEvolution client?