Re: [Evolution-hackers] Status of the DBus port, future plans

[Chenthill <pchenthill novell com>]

On Tue, 2009-01-13 at 14:50 +0000, Ross Burton wrote:
> 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().
We have been doing a lot of workarounds to achieve async behavior for 
other api's in evolution. The dbus port would help in fixing them!!

> 
> 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?
Its better to change the API in this case.  We can probably list down
owners for the external backends like scalix and inform them about the
change while getting it into trunk. I assume this is going to be in for
GNOME 2.28, so we have enough time to inform them and to let them make
changes. This is a welcome change and am completely for it!!


thanks, Chenthill.
> 
> Ross
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers