Hi,
As some of you may have noticed, there is a "dbus" branch in EDS now.
At present it contains a minimal port of the addressbook part of
eds-dbus to a fairly current (~1 week old) EDS tree. This mostly works
and after a little cleanup should be ready for more testing. However
there is a small problem with the calendar port which will take a bit of
explaining.
First an overview of some technical details as background. The ORBit
addressbook and calendar have an "interesting" design which is as
follows. The client makes one-way method calls to the server, which as
the name implies do not respond. The server then makes one-way method
calls to a listener interface on the client, which then determines what
method call in the client this corresponds to. The addressbook has
integer operation ids to do this, whereas the calendar code doesn't
allow simultaneous calls because it has the notion of a "current"
operation. This isn't a great problem for the calendar, because the
only async method it has is open().
The thing is, this design has effected the design of libedata-cal. The
DBus port uses a cleaner design of method calls having return values,
which thanks to DBus and dbus-glib is trivial to implement on both the
client and server. The addressbook backends use the operation ID as a
entry into a hash table of DBus method contexts, but the calendar
backend API doesn't have anywhere to put the method context.
I'll cut to the chase. This is an example of the current prototypes in
e-cal-backend.h, which is the interface backends (file, webcal, etc)
implement:
void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, const char *uid, const char *rid);
The current eds-dbus uses this:
void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, DBusGMethodInvocation *context,
const char *uid, const char *rid);
Note the addition of the DBus method context, so that the (potentially
much later) reply can be sent. I'm going to change it to something like
this:
void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, EServerMethodContext *context,
const char *uid, const char *rid);
Where EServerMethodContext is an opaque pointer, so the backends can't
do anything with it apart from pass it back to the server. Internally
it will remain a DBusGMethodInvocation*.
So, the gist of this rambling message is this: to merge the DBus port in
the current state I'd need to add a context argument to all of the
methods in e-cal-backend. This will break API and I'll obviously be
fixing the backends which are shipped as part of EDS at the same time.
The good news is that the e-cal-backend-sync helper class effectively
shields users of that from the change, so this affects less backends
than you'd expect.
The alternative is to clone the ORBit API with DBus and use oneway
methods and the listener object. This is substantial pointless
complication and won't allow us to add missing async versions of the
entire ECal API in the future, so I'm voting against this.
Any comments?
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://burtonini.com
Attachment:
signature.asc
Description: This is a digitally signed message part