gnomecal/evolution vs gnome-pilot

[Eskil Heyn Olsen <deity dbc dk>]

Oy...

Disclaimer ; my fever is just gone, it's late, and I just ate a huge
amount of chicken vindaloo.

I'll just make a summary of the problem for those who're not already
involved ;

The current biggest problem in gnomecal is the deletion problem. When
gnomecal deletes a record, it simply goes *poof* and dissapears (kindof
like your Fun with Bonus if you tilt... aw forget that).

Then comes the conduit, wanting to sync the pilot and make the user happy.
Now the user deleted the record on the pc, and assumes that after a sync,
it'll be deleted on the pilot as well. But no, it is not. Why ?

Because the conduit cannot detect deleted records, after all, they went
*poof*. This is where I could type a lot of possible workarounds, but they
all end at ; 1) too slow, sync has to be fast, 2) hack to implement a
feature that is missing from gnomecal.

The new evolution IDL solves this, by apparently using the Observer
pattern. This would let some gnome-pilot component sit and listen to the
calendar, be notified of events such as creation of new records (thus
sparing the expensive iteration over only-new-records that the gnomecal
conduit has to do now), but more importantly, be notified of deleted
events, and remember these.

Sounds swell, how ? The IDL defines a Evolution:Calendar:Listener
interface which has obj_updated and obj_removed (see (1)). Somewhere in
gnome-pilot, something has to listen to these. Certainly not gpilotd! This
is conduit specific, and if eg. people are using some other
calendar/address software, there is no reason to "pollute" gpilotd with
this. A gnome-pilot-evolutiond would be more appropriate. It'd register to
whatever listeners evoltion defines (see (2)), maintain a local db that
that the conduits can use when synchronizing, after sync, purge it.

So common scenario will be ; relevant conduits are enabled, evolution and
the gnome-pilot-evolutiond (devolution ? teehee) is running and storing
the data. Upon sync, conduits do their thing, and can delete the data
directly.

People disable the conduits ; gnome-pilot-evolutiond still captures the
data, so when the conduits are later reenabled, conduits can access the
data. If people do not reenable the conduit (non-detecable btw), the
captured data will grow... There has to be some mechanism to say "look
dude, you're not synchronizing the calendar, are you planning to or can I
stop capturing the data ?"

Horror scenario ; the gnome-pilot-evolutiond is not running ! (yeah, it
crashed). Well, with session management and whatnot, it could probably be
up almost all the time, but we all know that's not how the world is. And
this would leave timewindows where the data was not captured for the
conduits. Either this is just too bad, or we could try to solve it. Since
this gnome-pilot-evolutiond is quite evolution specific could this daemon
be registered in evolution as a  required-running thing ? The conduits
should be packaged with evolution anyways.

This would also give an extra bonus ; if people just toy with evolution
for a while, do some syncing and nothing more (and the daemon is started
by evolution). Then when they decide they don't need a calendar more in
their life and they disable the gnome-pilot conduits and never start
evolution again, the daemon won't be started (since it's controlled by
evolution (see (3)).

So the summary is ; The listener will solve most of the problems. The
problem is then with the listener - ensuring that it is listening.

Think thats enough rambling for today - next commentator please.

Footnotes ;

(1) Why not make this one call ?
	object_change(in CalObjUID uid, in CalObjChange change_type);
where changetype is an enum with UPDATED, REMOVED, ADDED. This opens for
other possibilities, like the ARCHIVED flag, plus I suspect the code on
both sides will be quite similar for all types of changes. On the other
hand, the amount of changetypes is not one that will grow unexpectedly,
so an interface with one enumerated call is not required.

(2) All the problems with the calendar hold up for addressbook. I peeked
at the idl for addressbook in evolution. It appeared to have a listener
interface, but not the same (is it not possible that it'd be better they
where the same ?) And as for the methods in this listener, see (1) again.

(3) If this is a general register-listener scheme, other listeners for
syncing/updating whatnot could also be added, thereby ensuring a higher
level of consistency with whatever programs that might want to listen to
evolution.

/dev/eskil
---