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 -- [email protected] http://www.estamos.de/ _______________________________________________ Evolution-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-list
