Re: gnomecal/evolution vs gnome-pilot



On Thu, 9 Mar 2000, Carlos Morgado wrote:

> Circular buffers. Then the problem becomes how big is a sensible buffer for

Configurable = "big enough" :) I none of the solutions should the purge of
deleted and non synced records be done without either notice or ability to
change it via configuration.

> 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 ? 

You missed something :) gpilotd is not interested at all in any of this,
it is conduit specific stuff and should (if choosen) only be used for the
evolution conduits.

If the conduits need to retrieve the data through gnome-pilot-evolutiond
instead of reading from disk (for locking or whatnot), they can start the
service through the OAF.

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

This scheme is an attempt to ensure that evolution doens't need to know
about pilots. At most that there are some services that must run when
evolution runs to ensure that "other programs" are notified of changes to
the evolution data.

/dev/eskil
---



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