Basic rationale of the KEP #2 design

[Shawn Walker]

Since I was mentioned in this discussion, I thought I bring a little more info about the Windows
compatibility with Olsen timezone.

For us, the only big issue is to write a Olson Timezone to/from Outlook (Windows) Timezone since we
cannot depend on the name of the timezone to translate to Windows, we have to resolve the timezone
by looking for the time zone string from the Olsen database and then we need to translate the Olsen
timezone information into Windows.  Also reverse the process.  I'm not sure if that we will be able
to cover 100% of the different timezone data between the two different set of timezone data, but we
can come close.

Regards,
Shawn

On 3/2/2011 8:06 AM, 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

-- 
Shawn Walker
Senior Software Developer
swalker at bynari.net
Bynari, Inc.
222 W Las Colinas Blvd, Suite 1320N
Irving, TX  75039
http://www.bynari.net
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax