Re: gnomecal/evolution vs gnome-pilot

[Carlos Morgado <chbm chbm nu>]

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 ?
> 
[snip]
> 
> 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 ?"

Circular buffers. Then the problem becomes how big is a sensible buffer for
"common" use and what is common use ?

> 
> 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.
> 
The evolution components should spawn it. definitly.

> 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)).
> 

either i missed something or this raises a gpilotd <-> gnome-pilot-evolutiond
connection problem. what happens if evolutiond is not running ? gpilotd spawns
it to check for records ? or just leaves it alone assuming the whole thing is
not used ? 
 
> So the summary is ; The listener will solve most of the problems. The
> problem is then with the listener - ensuring that it is listening.
> 

If evolution is configured to use pilot and doesn't ensure stuff is passed to
the listener then it's broken :)

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds