Features outside of the Kolab format

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

> On Thursday 01 November 2007 08:45, Gunnar Wrobel wrote:
>> The downside:
>>
>>  The Kolab format is limited.
>
> This can also be considered a strength.
> To my eyes iCalendar has too many variants, 
> keeping something simple and straight raises the chances 
> to get it implemented in a good way.
>

Of course.

>> Many clients by now offer features beyond what is specified within the
>> Kolab format.
>
> As the clients are different, they will always have some features that do not 
> fully match. Kolab tries to find one (out of several possible) common 
> minimum-set.

Fine with me.

>
>> What do developers do in case a Kolab client offers additional
>> features that are not being described within the Kolab format?
>>
>>  They implement it.
>>
>> This leads to the interesting situation that all the Outlook
>> connectors implement any groupware object attributes that lie outside
>> of the format specs in their own special way and are incapable of
>> understanding each other concerning those attributes. 
>
> As far as I have understood there is the technical difficulty, 
> that any Outlook plugin can add attributes to the internal Outlook message 
> object. So the full set of possible attributes is not known.
> For many users those plugins need to work, so one easy way is to save the 
> message object somehow in a windows specific way.
>
>> I think it would be good if the Kolab format development process would
>> better accommodate for the fact that clients progress and offer
>> features beyond the boundaries of the format specifications.
>
> I agree, but I could also say: It already does.

I fail to see that :)

> The main problem with format changes is client 
> and server implementation support and most current clients 
> seem to be conservative. 
>

I didn't make myself clear enough: I don't want to change the core
Kolab format itself. I don't want it to cope with every little client
feature I can think of.

> The process is to convince a significant number of people with a proposal
> to change the format over this list. 

This is also okay.

All I want is to allow format extensions and REQUIRE their declaration.

I suggest to add a line in the Kolab format specs that says that a
client MAY NOT extend the format with custom additions UNLESS they are
being announced on this list and stored on a wiki page for further
reference. If the client violates that it is no longer a Kolab
compliant client.

I fail to see how the Kolab format deals in an appropriate way with
extensions at the moment. The clients by now start to move into areas
left undefined by the Kolab format. As you already mentioned this is
bound to happen.

In most cases these extensions are not being announced. But even if
they are it is unlikely that they are being included into the format.

Look at my posts suggesting a new way on handling the Horde
preferences: While this found a conclusion and the preferences will
continue to be stored in LDAP this does not change the fact that I
have a need for the IMAP based driver. Of course I'm unable to get
this into the format so what will I do? I'll probably add it as an
optional module anyhow in Horde without ever bothering about the
format specs.

The few customized attributes that have been added to Kontact and
Outlook are mentioned nowhere at all. The reason is simple: As a
client developer the effort is significantly reduced by just
implementing new features without bothering about long discussions on
this list.

But in the long run this causes compatibility problems. If I'd like to
add a "blog feed" attribute to contacts in Horde and I never used
Kontact before, how should I know that Kontact already uses an
internal definition for this attribute? If I'd like to use a "company"
attribute on a task I could by now choose between three different
implementations from three different Outlook connectors. Or I might
implement all three :)

If these things would be public it would be far easier to keep the
other clients compatible even if these extension are not an integral
part of the Kolab format.

Cheers,

Gunnar

> Best,
> Bernhard
>
> -- 
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~