Basic rationale of the KEP #2 design
Joon Radley
joon at radleys.co.za
Wed Mar 2 18:23:07 CET 2011
On 02 Mar 2011, at 4:06 PM, Florian v. Samson wrote:
> Georg, all,
>
> I still fail understand the basic approach being taken in KEP#2 after
> reading through the extensive discussion over the last couple of months,
> again. Hence I will write up a top-down description my understanding of
> then situation and the partial lack thereof.
>
> Looking at the basic design decisions of the current Kolab Format, the
> choice of XML along with the clear statement that any XML-tags unknown to a
> client must be ignored was made to allow for easy extension of the Kolab
> Format (among many other properties) while retaining backward
> compatibility, by specifying new XML-tags. Any other measure to extend the
> Kolab Format implicitly breaks backward compatibility, which must be
> avoided for a specification with many implementations in order to stay
> commercially successful, as it loads the burden of maintaining two
> implementations for (at least) a while on every implementer and carries the
> risk of an format fork, if not all implementers (are able to) follow the
> incompatible format changes, for technical or other (e.g. costs) reasons.
> Only if a design issue can solely be cured by altering existing XML-tag
> definitions in the Kolab Format such an approach is inevitable, which is
> not the case for the design issues KEP#2 is trying to address. (I will
> come up with a suggestion in a follow-up email.)
>
> I also do not comprehend on a more practical level of design, why an
> external technical dependency has to be introduced, specifically on a
> timezone database. Currently there is no necessity for a Kolab Format
> parser to depend on any other software components; this property can and
> should be retained, as it is used by many implementers. Specifically the
> Olson database seems to be excellent per se, but a good specification
> should not stipulate a decided implementation and preclude others, as long
> as the required properties of the Kolab format can be attained.
>
> Consequently all implementers of Kolab clients have expressed issues with
> KEP#2, which are still present in its current state, with the sole
> exception some of the Kontact client implementers from Kolab Systems (Georg
> Greve and Jeroen van Meeuwen):
> a. All have expressed reluctance to significantly change existing parser
> code for KEP#2 and to maintain two incompatible variants of their
> individual Kolab format parser in parallel, specifically Hendrik Helwich
> (Syncphony and Evolution-kolab), Gunnar Wrobel (Horde) and Christian
> Hilberg (Evolution-kolab).
> b. Gunnar, Hendrik, Christian and Bernhard Reiter (Kontact) have also
> expressed reluctance to depend on external software libraries, e.g. for
> parsing date-time tags with full RFC3339 support. Hence, extending the
> existing date-time tag to cover full RFC3339 compliance either forces a
> client implementor to spent a significant programming effort or to depend
> on an external library.
> c. The same applies to SyncKolab (Nico Berger's Thunderbird plug-in) and to
> the Toltec and Bynari MS-Outlook plugins, from what I gathered from Joon
> Radley's (Toltec) and Shawn Walker's (Bynari) postings on this list.
> d. In certain programming environments the mandated external dependency on
> the Olson database and the suggested one on a RFC3339 parsing library is
> extremely hard to impossible to fulfil. Joon and Shawn clearly stated so
> multiple times for the perspective from an MS-OL plug-in and supposedly the
> same applies for the Synckolab Thunderbird plug-in in its Mozilla's
> JavaScript & XML "XUL" environment. Please accept that these programming
> environments bear many more constraints than a regular MS-Windows (as
> addressed by Georg) or Java (as noted by Jeroen) environment.
> e. It is more than likely, that a. - d. also applies to the Konsec MS-OL
> plug-in.
>
> The stated inability of at least two major Kolab clients to follow the
> proposed changes in the Kolab Format on a structural level makes me worry
> about the future of the Kolab environment as a whole: the fact that
> multiple Kolab clients on different operating systems- and PIM-environments
> (Windows, GNU/Linux, Kontact, MS-Outlook, WWW, etc.) are well established
> and interoperable always has been a big asset. To loose that by separating
> the Kolab clients in those which do support the new format version and
> those which do not, will significantly hurt the attractiveness of Kolab.
>
> So I kindly ask the proponents of KEP#2 to help me and others to understand
> why the fundamental design considerations of KEP#2 must create these
> significant hurdles for the whole Kolab environment.
>
> Thanks
> Florian
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
I agree with Florian 100%.
Best Regards
Joon Radley
Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at toltec.co.za
Web: www.toltec.co.za
More information about the format
mailing list