Comment 6 for bug 1342123

Small update:

> Bill Filler (bfiller) wrote on 2014-09-23:
> I'm assuming evolution-calendar-factory gets loaded by indicator-datetime initially such that the indicator can show calendar events.

As a troubleshooting step, I tried disabling the Upstart entry for indicator-datetime-service so that it doesn't get started and respawned automatically, and launched it manually using the terminal. Sure enough, evolution-calendar-factory starts only after indicator-datetime-service starts, and stops a few seconds after the indicator-datetime-service process is terminated (by Ctrl-C during my testing).

So what actually happens in the workaround I posted earlier was that invoking another instance of evolution-calendar-factory manually will sever the link that the date/time indicator has to the calendar service. The new, manually invoked evolution-calendar-factory instance that replaced the old one will then terminate itself after a few seconds.

It should be fine for people like me who never use the calendar, but people who do use the calendar should watch out.

There are a few questions I can think of at this point:
1. Is it by design that indicator-datetime-service needs continuous access to the org.gnome.evolution.dataserver.Calendar4 D-Bus service?
2. Does it really need to maintain a connection to that service even if the user doesn't use the calendar feature at all? (this needs to be asked because the current implementation of evolution-calendar-factory occupies an above-average amount of memory, even for empty calendars)
3. If not, what could be preventing it from disconnecting from the service once it's done with its business?

I'll try to see what else I can uncover.