Re: gnomecal/evolution vs gnome-pilot

[Erik Bågfors <bagfors pdc kth se>]

On Thu, Mar 09, 2000 at 01:46:41AM +0100, Eskil Heyn Olsen wrote:
> 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.

what happens if you move back and fourth between two different calenders
(one at home and one at work for example) will a slow sync still happen?

Once I did a perl-program that synced the pilot to a vcal-file and it
solved this problem very easy.  The program created a small "database"
which mapped the pilot-id to the vcal-id for each event.  When an event was
deleted it was still in the database.  When the program looked in the
databas and found it but didn't find it in the vcal-file it knew it was
deleted.

I can't see how this can be to slow.. maybe it's a bad hack but I don't
think so.  All you would have to do is create a small file with all the
id's of the vcal-events and you are set to go.

Alot less "hacky" then running another process imho.
/Erik

-- 
Erik Bågfors               | Center for Parallel Computers
http://erik.bagfors.nu/    | http://www.pdc.kth.se/
erik@bagfors.nu            | bagfors@pdc.kth.se  
Supporter of free software | GSM +46 70 398 54 43