Basic rationale of the KEP #2 design - Part 1

[Georg C. F. Greve]

Dear Florian,

On Tuesday 15 March 2011 13.59:22 Florian v. Samson wrote:
> Good, so let us create a solution for the identified TZ-issues, which
> compatible with the existing Kolab-format.

That would be possible if the existing Kolab format were capable of handling 
the use cases we discuss, and KEP 2 were addressing an implementation issue.

But KEP 2 is addressing a conceptual mistake made in the Kolab format. 

So retaining full compatibility in all directions would necessarily retain the 
issue that KEP 2 is aiming to resolve. No matter what kind of solution we end 
up with, resolving the issue will inevitably break compatibility between older 
and newer clients to the extent that older clients will not be capable of 
correctly interpreting and displaying the data written by newer clients.

At best older clients may be able to incorrectly display an event, and store 
it wrongly upon modification, but that is the "best case" scenario, and it does 
not seem convincing.


> A specification cannot be "broken", as it defines things to be this or that
> way, except for the case where a specification itself contains clearly
> conflicting statements.

That is one way to define "broken."

Another way would be to say a specification is broken if it cannot actually 
address the  use case it is supposed and claiming to address, or does it in a 
way which necessarily delivers faulty results.

This is the way in which I am using the term.

But I don't think that arguing semantics is necessarily bringing us closer to 
resolving the issue, so I suggest to look beyond them.


> What else is the "loose parsing" about you and Jeroen are pushing for so
> hard? It is for allowing clients to utilise the specification in a very lax
> manner!

No, actually.

It is for clients to be capable of providing value to the user even when the 
user makes the mistake of connecting clients that are partially inconsistent 
with the specification so that the overall solution will continue to work well 
while those inconsistent clients get fixed.

It is, in other words, about higher fault tolerance in the overall system, 
which in Kolab is a good idea because it is such a diverse and complex 
ecosystem with so many different clients and components.


> > So you're 100% certain that Evolution does not offer APIs for tz support?
> 
> Georg, IMO this is completely the wrong approach: [...]

You've repeatedly stated that neither the Evolution connector nor SyncKolab 
could implement KEP2, although neither of the people working on the code for 
them have raised similar points.

So I think it makes sense to ask to substantiate those claims.


> if you are seriously interested in having as many Kolab-clients as there are
> interested initiatives / companies, you should ask yourself "can I expect
> any PIM-Client, which may be extended to become a Kolab-client in the
> future, to have an integrated and easily accessible full RFC3339
> implementation". The answer is "No",

Could you substantiate that answer? What groupware clients do you expect to 
work on platforms without emailing and network capabilities?


> Especially for Thunderbird and Lightning with their often heavily changing
> APIs I cannot tell with the "absolute certainty" you requested (as I looked
> at those APIs a while ago, when I retraced Synckolabs design and its
> limitations), though I am quite sure that no RFC3339-parsing API was
> introduced, as it simply makes no sense. 

While I have not had time to dig deeper into this, the existance and 
resolution of

 bug 475803 - cal.fromRFC3339 matches fails to set timezone correctly

in the Google calendar plugin for Mozilla Thunderbird would seem to indicate 
that both RFC3339 and time zone support is available for Thunderbird plugins.

https://addons.mozilla.org/nl/thunderbird/addon/provider-for-google-
calendar/versions/


> And even if a full RFC3339 parser would be accessible, those APIs seem to be
> redesigned with every major release, so they are not future proof at all.

That would appear to be an argument against investing into paying too much 
attention to SyncKolab and Thunderbird, but not so much against KEP2, as 
changing APIs would affect the entire code, not just RFC3339 parsing.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110321/4a002300/attachment.sig>