Basic rationale of the KEP #2 design - Part 1
Georg C. F. Greve
greve at kolabsys.com
Mon Mar 21 13:20:58 CET 2011
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
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
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.
> 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.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format