Re: [SyncEvolution] SyncML + OBEX

Hi Patrick, When will your defined API for OBEX server/SyncML client be ready? I'll work on this fulltime and need the SyncML client code to do the debug/test. Thanks, Forrest -----Original Message----- From: Ohly, Patrick Sent: 2009年8月21日 18:50 To: Zhao, Forrest Cc: SyncEvolution; Holtmann, Marcel Subject: RE: [SyncEvolution] SyncML + OBEX Hello! I'd like to revise the D-Bus API a bit. See below. On Wed, 2009-08-05 at 11:25 +0200, Patrick Ohly wrote: I think we should, and there may be more types of optional information that we might have to add in the future. Therefore I suggest to replace Connect(peer_description, peer_id, transport, ...) with Connect(peer, ...) where peer is string->string dictionary with the following predefined keys: "description", "id", "transport", "transport_description". All of these are optional in the context of OBEX, but providing some of the information for debugging purposes would be useful. The advantage of the dictionary is that we can add other auxiliary information later on without breaking the API. The disadvantage is more complex method argument encoding in obexd. dbus_message_append_args() does not support dict entries, one has to use an iterator. Here's an example: const char *key = "transport"; const char *value = "org.openobex.obexd"; DBusMessageIter sub; dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, "{ss}", &sub); DBusMessageIter entry; dbus_message_iter_open_container(&sub, DBUS_TYPE_DICT_ENTRY, NULL, &entry); dbus_message_iter_append_basic(&entry, DBUS_TYPE_STRING, &key); dbus_message_iter_append_basic(&entry, DBUS_TYPE_STRING, &value); dbus_message_iter_close_container(&sub, &entry); dbus_message_iter_close_container(&iter, &sub); The arguments before and after this dictionary can be appended normally. For similar reasons, I suggest to move the connection.response() response_url retval into a dictionary. This dictionary can be skipped when parsing the reply. -- 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.