Re: gnomecal/evolution vs gnome-pilot

Eskil Heyn Olsen wrote:
> 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.

I believe the GnomeCal format currently keeps a timestamp on the record
allowing it to say if it is new or not.  Why not add another line that
shows that the record has been deleted.  After a decent amount of time,
say one week, or first sync, trash the record.  I do not believe in
CRUDE hacks just to do syncing... and my suggestion may be crude, but it
isn't totally insane like adding another running process to the
calender.  GnomeCal is the data store, not the conduit, and it should
stay that way.  Why do I want another program adding more data to my

Trever Adams

(Yes, so I usually sit silent on this list... but this is how I feel)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]