Re: [Evolution] Problem viewing calendars on multiple machines

[Patrick Ohly <patrick ohly gmx de>]

On Wed, 2009-03-11 at 09:25 +0000, Chris G wrote:
> On Wed, Mar 11, 2009 at 12:11:45AM +0000, Pete Biggs wrote:
> > > Ummmm... no offense, but just looking at your instructions for changing 
> > > machines makes me think that the design of evolution is a bit insane.  I 
> > > really don't feel like what I want to do should be that difficult.  I figured 
> > > since evolution is the default calendar for most linux systems, it wouldn't 
> > > be... well such a pain to work with on multiple machines.
> >
> > The issue really is that Evo is a client program, it was never designed
> > to offer the data that it uses to other programs, it was designed to be
> > a consumer of data from elsewhere.
> The whole "synchronization" process is a can of worms in my opinion,
> the idea that you need a 'server' and separate clients makes it all so
> unnecessarily complicated for the situation that 99% of users want -
> synchronization of desktop and PDA (or laptop in the OP's case).

Unfortunately many of these complications are inherent to the problem,
like format differences between heterogenous users of the data and
concurrent modifications of it. By limiting yourself to just one
application (and just those versions of it which use the same file
format) and by avoiding concurrent modifications, syncing becomes
easier, but I doubt that this is what 99% of the users want.

You mentioned desktop and PDA: that already are two different
applications which probably need format conversions.

> It is possible to synchronize my E71 with Evolution, using the
> Evolution syncMl add-on plus a syncMl server but it's messy and either
> needs a server 'out there' or you install Funambol which again is
> *huge* (164Mb for a syncMl server, what it's all for?)

The Synthesis server is smaller (C++ instead of Java + bundled Tomcat
Application Server). OpenSync probably also will be smaller.

> I'm about to investigate what I can due using WebDav, it seems to me
> that's the right approach, share a single chunk of data between all
> applications rather than trying to 'synchronize' different lumps of data.

If all your applications support it, that indeed is a simpler solution.
But many devices that people need to synchronize with don't.

Regarding the role SyncML in mitigating format incompatibilities: as was
said already, the language itself is format agnostic. It is commonly
used with some standard formats (vCard, vCalendar) that need to be
supported in addition to SyncML itself. SyncML does have the means to
communicate to the server which parts of these standards its clients
support. Good SyncML server implementations use that information to
translate between clients and preserve information that one side doesn't
support.

That is also the reason why there is a central, more capable server in
the middle: you really don't want to have that complexity in each and
every client implementation. Whether that server is installed on the web
or a desktop machine is an implementation and deployment detail (albeit
an important one).

If synchronization in such a setup doesn't work satisfactorily, then
file bug reports or enhancement requests. It is difficult to get right,
but it isn't impossible. I'll certainly do what I can in SyncEvolution.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/