Re: [Evolution] Sync or share....do multiple instances work?

[Not Zed <notzed ximian com>]

On Fri, 2002-06-07 at 15:39, Joshua Rochester wrote:
> Whoops...forgot to send to the list :) Hi Zed.

nevermind :)  i've bounced this back to the list.

> On Thursday, June 6, 2002, at 11:08 PM, Joshua Rochester wrote:
>
> > On Tuesday, June 4, 2002, at 05:47 AM, Not Zed wrote:
> > > > On Sat, 2002-06-01 at 05:09, Joshua Rochester wrote:
> > > > > I'm looking to run Evolution on multiple systems simultaneously, 
> > > > > and I
> > > > > want to make sure what I'm doing won't corrupt the databases for
> > > > > contacts, tasks, and calendars. Do any (all) of these configurations
> > > > > work without conflict?
> > >
> > > In short - no.
> > >
> > > Of course, if you're contacts are in an ldap backend, etc etc things
> > > like that work.  But even stuff like imap doesn't support multiple
> > > clients (yet).
> >
> > I use UW-imapd with my mailboxes converted to mbx format (not plain ol 
> > mbox) and I am able to use multiple simultaneous clients and changes 
> > synchronize and there are no locking issues. Cyrus is also supposed to 
> > be able to do this. Or did I misunderstand the limitation you suggest?

Well, evoluiton doesn't currently even work very well if you have
multiple clients accessing the same mailbox with imap.  Its a limitation
with the imap code.

Also, if you are using the same ~/evolution - well, it assumes it has
total exclusive control of it, so you could end up with messed up
summaries and cache, although your mail would still be intact since its
server-stored.

> > > Anyway i just tested it.  Logged into the same box, with a different
> > > display and re-ran evolution.  All I got was another copy on the same
> > > display as the first one.
> >
> > Confirmed. Re-running evolution just opens another window on the 
> > original display no matter which display the evolution task is run 
> > from. Probably needs some error checking to prevent user problems?

I'm not sure if we can even do that, because the object activation is
handled by the corba/middleware layer?

> > > > > 3) Running a file synchronization utility on live data files to allow
> > > > > disconnected clients to share the same profile?
> > >
> > > You could:
> > >  end up with stale data (e.g. config changed, not committed to disk)
> > >  end up with corrupt data (the file changes while you're reading it)
> > >  end up with good data, sometimes.
> > >
> > > You really just have to logout of one first and login to another one 
> > > for
> > > this to work.
> >
> > Confirmed. Running unison I was able to sync configs...but it does not 
> > appear that data is written by the client until the entire evolution 
> > stack is terminated. Killev was necessary before sync (on both sides) 
> > in order to have data appear on the slave.

Some of the data is written as it gets changed, but most of it is only
read once.   Although filters are read/written every time, so they're
one of the few things that this would work with.

> > Two new thoughts:
> > 1) Browsing through the list archives I noticed that some people use 
> > their Palm devices to synch between installs. Perhaps there is a way to 
> > use the gpilot conduit to a dummy palm (a file or set of files) to 
> > provide a sync method (I'm mostly talking about 
> > calendar/tasks/contacts, since IMAP handles the mail)? I can't tell 
> > from the limited gpilot documentation on the gnome site.

Hmmm, I guess that may be possible.  Although it does sound like a lot
of work.

> > 2) Again inspired by the Palm sync mechanism....clearly there is a way 
> > to disconnect and reconnect to the data store. Perhaps some CLI 
> > utilities could be generated that send the disconnect/reconnect signals 
> > so that file synchronization could be performed? It wouldn't be like 
> > operating in real-time sync, but a frequent cron job might just be 
> > 'good enough'.

Yeah that might be an idea.  Or a way to shutdown the other instance if
it is running on the wrong display.  Again, i'm not really sure on this
(i'm just a lowly c hacker, i've avoided the corba stuff), as i think
its handled by the middleware layer, but I guess it must be ... even if
you just send it a 'file->quit' menu option via bonobo or something and
wait for it to exit (or something equally 'hacky').  There has to be
somethign better than just running 'oaf-slay' though.

Maybe someone on the list has an idea ...