Small extension to the annotate proposal

[Martin Konold]

Am Dienstag, 29. Juni 2004 11:17 schrieb Bo Thorsen:

Hi Bo,

> On Tuesday 29 June 2004 10:43, Martin Konold wrote:
> > Am Dienstag, 29. Juni 2004 10:41 schrieb David Faure:

> > > I like the idea of adding
> > >  /vendor/kolab/storage-format where value.shared would be "xml 1.0"
> > > (referring to the kolab xml storage version 1.0". This would allow to
> > > set it to 2.0 in case of major changes later, and it would also allow
> > > values like "ical 1.0" or "vcard 1.0".
> >
> > This is exactly what I want.
>
> As agreed later in this thread, versioning should not go into the
> annotation.

Sorry, but your thoughts are short sighted. We can never know what a kolab 
calendar will contain in the future. The arguments given in this thread sofar 
have not been convincing to me as they miss the point.

The storage format description is _not_ required for _reading_ messages (as 
Joon correctly mentioned this information is already in the mime-type) but it 
is _required_ for _writing_ to a folder. Otherwise a client does not not know 
which format is expected for writing to a folder. 

This point is especially important with shared folders _not_ belonging 
directly to the user.

> I also disagree that we should add format here.

Adding an extra format annotation is best for future backwards compatibility.

> Instead, I would propose 
> that whoever does annotations on other types of formats in these kolab
> folders just do something like /vendor/kolab/ical/calendar
> or /vendor/kolab/ical.calendar. That would mean they can do whatever they
> want.

This is not a good idea as it makes transitions from one format to the other 
unnecessarily more complicated. E.g. when moving from Kolab XML Format 1.0 to 
XML Format 2.0. IMHO it would be really short sighted to assume that our XML 
Format 1.0 will last for ever. 

It might even be required at some point to run some special conversion script 
on an old XML 1.0 Kolab installation (e.g. all folders) before XML 2.0 can be 
used etc. 

One new client capable of writing old XML 1.0 and new XML 2.0 format must be 
prevented from writing XML 2.0 in case of mixed client environments. 

E.g. 
- User A owns folder F 
- User B has write access to folder F
- User A and B have a Kolab 2.0 client installed using Kolab XML Format 1.0
- User A and User B are happily working together
- User A is on vacation
- User B upgrades to the latest and greatest Kolab 2.1 client 
- User Bs Kolab client already knows about Kolab XML Format 2.0
- User B writes to the shared folder
- User B cannot know that User A expects still the old XML 1.0 format
- User B writes to the shared folder F
- User A returns from vacation
- User A is unhappy about User B writing in a format to his folder which User 
A cannot parse correctly

Using the proposed Kolab Format annotation would have avoided this situation 
nicely as it would have allowed User B to write to the folder F with the 
compatible XML 1.0 format.

In general we should not expect _every_ client to be updated at the very same 
time in larger corporation. Using the proposed annotation would allow a 
gradual roll-out and help a lot for stability and robustness of a Kolab 
deployment. 

> The Kolab format specifies the format when the annotation
> is /vendor/kolab/calendar (for example). Other formats can just choose
> something else.

IMHO we should cater for such semantics initially and not later let arbitrary 
parties add their own stuff. After all Kolab is primarily about a 
specification.

I really don't see the point why 

/vendor/kolab/folder-type event
/vendor/kolab/storage-format xml 1.0

should hurt?

Yours,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de