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: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com
Description: This is a digitally signed message part
_______________________________________________ Evolution-hackers mailing list Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers