Re: Gnome3/Gnome-shell Calendar backend

[David Zeuthen <zeuthen gmail com>]

Hi,

On Mon, Mar 21, 2011 at 12:57 PM, Giovanni Campagna
<scampa giovanni gmail com> wrote:
> So this calendar-server stuff is not a temporary HACK and gnome-shell
> will have a daemon running at all time for the calendar (even if
> evolution is not used)? I thought it would be removed when e-d-s
> supported async calls.

Not sure why you think it's a HACK ... FWIW, there are many many
instances where it's better to use a separate process instead of a
separate thread (and D-Bus was partly invented to enable things like
that). And the same way the other way around, btw. It really depends.

The trade-offs of process vs thread are also very well-understood I
think. For example, the current shell<->calendar-server interface
lends itself very nicely to a plug-in mechanism which could be (or
not) what we want. And processes (essentially, fork() + exec()) are
very very cheap on Linux. It's also a lot easier to debug something
that isn't your compositing manager....

In this case, I moved all the stuff into a separate process after
reviewing the e-d-s libraries. It was the only sane thing to do after
realizing that the code was using blocking IO and also using libraries
that are not thread-safe (GConf2).

Sure, it could be that that the e-d-s libraries gets fixed and that we
decide we only want to support e-d-s. In that case someone can move
the code back into the gnome-shell process. Then again, the cost of
the current setup is very low and for that low price we get a very
flexible model where we can easily swap out the calendar server code
at runtime. Which makes it easy for non-shell developers to hack on
calendar servers. Tradeoffs, you know :-)

> Native libraries are there for a reason. It would be as if we avoid
> using telepathy-glib, upower-glib or libnm-glib, fearing they could
> block or have bugs.

Did you go through and review all these libraries (and their
dependencies - such as GConf) to ensure that they don't leak and they
don't do blocking IO? No, didn't think so... FWIW, those libraries are
mostly just wrappers for a D-Bus API so it's probably fine as long as
you run the code from the main-thread as libdbus-1 is not
thread-safe...

    David