Kolab XML Format: The xCal/xCard based approach

Gunnar Wrobel wrobel at pardus.de
Sun Dec 11 22:31:38 CET 2011


Quoting Thomas Koch <thomas at koch.ro>:

> Bernhard Reiter:
>> Am Wednesday, 23. November 2011 15:14:37 schrieb Christian Mollekopf:
>> > [...] the kolab format
>> > is essentially already a subset of iCal/vCard (respectively their XML
>> > representation).
>>
>> No it isn't. The problem is that the difference are so subtle to many
>> people that they will overlook them and implement problems. Using your own
>> format is a stop-gap against this measure.
>
> Hi Bernhard,
>
> sorry for my naivety, just for clarification:
>
> I've heard/read this argument now a couple of times, that kolab xml was
> invented, because iCal/vCard implementations were incompatible. But  
> I couldn't
> find any list of these incompatibilites. On the other hand Georg  
> Greve pointed
> out, that there is now the effort of calconnect.org to work out
> incompatibilites and have regular "plug-fests".
>
> How does your justification of the kolab format differ from this XKCD?[1]

This is easy: The Kolab format does not try to cover all use cases.  
Quite the contrary. It tries to provide a data structure so that the  
Kolab server clients are able to provide the same user experience - no  
matter what Kolab client is being used.

>
> Since you have to implement kolab xml anyways in all clients, wouldn't it be
> less effort and more clever to fix those clients so that they implement the
> already existing standard correctly? Maybe older vCard/iCal may have had
> issues, but does the same still hold true for xCard/xCal?
> Developing a standard is a lot of work. Wouldn't it be wiser to use already
> existing standards instead and collaborate with calconnect, like eGroupWare
> and DAViCal?

My personal opinion: In a way, yes. I would like to see us being as  
close as possible to an already defined standard. This will definitely  
make it easier on the development side as there will often be code  
that can be reused. And as mentioned before the number of in-client  
conversions (usually from/to iCal/vCard at the moment) might be reduced.

But I wouldn't underestimate the effort of basing on these existing  
standards. I think it has already been mentioned that we are unlikely  
to just say: A Kolab client SHOULD implement the complete RFC to be a  
real Kolab client. For the Kolab world the Outlook compatibility has  
always been an important factor as well as an important restriction on  
what we could actually do on the client side.

I don't know if this is going to remain the same. But if it is I don't  
think we will have far less KEP's if we adopt the new xCard/xCal  
standards. These KEP's might just be used to clarify the expected  
client behaviour associated to certain data values. And some of the  
possible properties in the standards we might even want to declare as  
invalid and not to be used within the Kolab world because we see no  
option of supporting them for the complete range of available Kolab  
clients.

> On the other hand, the Kolab format is regarded as underdocumented, lacking a
> test suite and tools.[2]

I fully agree with the analysis concerning the problems of the Kolab  
format that you linked here. In its current state it has some severe  
problems. But the stream of KEP's we had this year had quite a  
different quality to me. If a new version of the Kolab format would  
look similar to those KEP's I think many of those problems would be  
resolved.

But at the same time I can't fail to notice that the stream of KEP's  
we had was not immediately followed by a similar stream of notices  
saying: "Kolab Client X now claims full support of KEP Y". Not that I  
would have expected that.  But it illustrates one thing: The clients  
will not move very fast.

So what I would fear when simply adopting the existing standards: That  
it would destabilize the Kolab format. Suddenly we would loose central  
aspects of Kolab support in many of the Kolab clients that currently  
exist. I don't know if that is what we really want.

Bottom line: I'm pretty undecided concerning the topic raised here.  
But because of the possible destabilization I'd rather refrain from a  
simple "yeah, cool, lets use the new standards" - which is the  
impression I got from the initial posts.

Cheers,

Gunnar

>
> [1] http://xkcd.com/927/
> [2]  
> http://www.mail-archive.com/cyrus-devel@lists.andrew.cmu.edu/msg01877.html
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de





More information about the format mailing list