Re: [Evolution] Problem viewing calendars on multiple machines

[Patrick Ohly <patrick ohly gmx de>]

On Thu, 2009-03-12 at 08:57 +0000, Chris G wrote:
> On Wed, Mar 11, 2009 at 03:57:26PM -0430, Patrick O'Callaghan wrote:
> > On Wed, 2009-03-11 at 16:42 +0000, Chris G wrote:
> > > On Wed, Mar 11, 2009 at 11:57:40AM -0430, Patrick O'Callaghan wrote:
> > > If both ends use the same data file they *can't* disagree!  OK, it's a
> > > little more complex than this but to my mind it's fundamentally less
> > > broken then trying to bodge it with a 'translator' in the middle. 
> >
> > The OP talked about syncing two instances of Evo, so it *might* be true
> > that the data is in the same format (assuming they are both the same
> > version), but then you introduced the notion of syncing with other
> > devices such as PDAs, where the data files will definitely *not* be in
> > the same format.
> The idea behind using Webdav/Caldav or whatever is that it *makes*
> both ends use the same format.

And if that is not the case (bugs in the implementation, different
capabilities), then what?

You would be forced to not use the client which is at fault until it is
fixed/improved. With SyncML at least you have a chance to accomodate for
such differences in the server.

> > > SyncMl does 'know' about what it's transferring to some extent, if it
> > > doesn't then how is it any different from a simple file copying
> > > mechanism?  There are several very clever file synchronisation
> > > utilities already available, if that was all that was needed then
> > > SyncMl would be redundant.  Where SyncMl scores is that it *does* know
> > > the sort of things its transferring.
> >
> > SyncML is not a file transfer mechanism, or even a synchronization
> > protocol (despite the name). It's a description language. The only sane
> > way to interoperate N devices is to have an intermediate standard
> > format. That way the number of translations is O(N), not O(N^2). That's
> > what SyncML is for.
> Which confirms what I was saying - SyncMl does know (and thus
> *limits*) what is being transferred.  OK, SyncMl can be expanded as
> needed to allow more different clients to connect using it but
> ultimately it's a dead end because you have so many possible sorts of
> data being passed that no two ends ever agreee.

Minor correction: it is not "SyncML the protocol" which limits the kinds
of data that can be exchanged, it is "SyncML server XYZ" or "SyncML
client ABC" which only support certain kinds of data.

>   Or are you saying
> that the SyncMl "intermediate standard format" is effectively cast in
> stone?

No, it is not. The implementations choose that, with varying success.

> Using Webdav/Caldav to underpin everything means that essentially you
> say (in SyncMl parlance) that "these are the things I will transfer"
> and there are no more.  Ultimately you 'encourage' both ends to use
> .ics format data internally and *that's* when it all becomes
> relatively easy.

It's also too limited for many use cases. Do you know any mobile phone
which supports Caldav? Does it work while offline?

I suggest we stop this discussion. Caldav and synchronization (with
SyncML or other protocols) solve different problems. Choose whatever
suits your needs better.

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