Basic rationale of the KEP #2 design
Florian v. Samson
florian.samson at bsi.bund.de
Wed Mar 2 15:06:34 CET 2011
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
More information about the format
mailing list