Basic rationale of the KEP #2 design
Joon Radley
joon at radleys.co.za
Wed Mar 2 18:17:14 CET 2011
Hi Shawn,
> 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.
This is a MUST requirement. Since neither you or us can control this, no Outlook Kolab client can be KEP2 compliant or get certified.
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
On 02 Mar 2011, at 6:51 PM, Shawn Walker wrote:
> 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
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
More information about the format
mailing list