Basic rationale of the KEP #2 design - Part 1
Florian v. Samson
florian.samson at bsi.bund.de
Tue Mar 15 13:59:22 CET 2011
Georg,
Am Freitag, 11. März 2011 um 20:30:56 schrieb Georg C. F. Greve:
> On Friday 11 March 2011 16.41:08 Florian v. Samson wrote:
> > That is one reason why specifications must never follow or adapt to
> > broken implementations.
>
> Indeed.
Good, so let us create a solution for the identified TZ-issues, which
compatible with the existing Kolab-format.
> Which is why KEP #2 does not follow or adapt to the current
> broken specification and implementation,
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.
So the current Kolab-format is by no means "broken", it just has
the "little" disadvantage that all timestamps are in UTC only without a
separate timezone identifier, so changing the reference time for an event
to properly represent a local time needs some more information and
therefore new XML-tags.
> but proposes a clean solution that the implementations can then adapt to.
The "solution" KEP2 is a clean cut from the existing Kolab-format, as it is
incompatible, but that does not automatically make KEP2 a cleaner solution
than other ones.
> > Please be clear: which "several clients"? I only read
> > Kontact-developers stating that on this list.
>
> Joon said that the Toltec connector also does not preserve nested XML
> tags, so both implementations that are mentioned as the reference
> implementations for version 2 of the format do not show the behaviour
> upon which you suggest we rely.
Sorry, I did not state anything such.
You seem to completely misunderstand any of the more abstract and generic
points I made, which go beyond a single, specific technical issue.
I do not comprehend, why you are so eagerly discussing XML-tag preservation
in technical detail, after you stated that this shall be solved separately
(and I did and do agree). I made clear at least twice, that I merely
highlighted the general design principle of preserving tags in the
Kolab-format and that we should definitely maintain that as a principle.
Now, leaving the general principles aside for a second and diving into the
nitty-gritty details which dominated the discussion and the modeling of /
thinking about a evolved Kolab-format on this list so far, unfortunately:
Sure it might make sense to provide some additional time (though it has been
years already) for broken clients to finally conform to what always has
been stated in the Kolab-format. In contrast to many other things we
discuss here on this list AFAIK nobody mentioned a fundamental technical or
design hurdle for Kontact (and maybe also Toltec) to preserve all tags in
the foreseeable future.
Furthermore top level tags seem to be preserved by all existing clients:
so all the detours which have been taken in various directions throughout
this conversation about preserving tags are IMHO superfluous here (= in
this thread), as they are irrelevant for ...
a. recognising the underlying design principle in the existing Kolab-format.
b. extending the Kolab-format as intended by its original developers, by
introducing new tags. It imposes no hard restriction, if we limit that to
top-level tags, currently.
> > IMO it must be fixed in those clients, and loosening the specification
> > is a "anti-fix", as it calls all clients to use more leeway.
>
> As stated before, I agree with your suggestion to fix all clients to
> start preserving all XML tags. But as we know this is not currently
> something they do, we cannot rely upon it for this particular KEP.
You are proposing to model the specification (KEP2, here) following certain
client implementations, again, which is something you denied at the
beginning of your mail.
Even the two reference clients (and those two have been the reference
clients since the Kolab2 development started) constitute references only
for those cases, where the specification is unclear, imprecise, ambiguous,
or even inconsistent or things are simply unspecified (as the case for most
behavioural aspects of a Kolab-client): in all other cases, the
Kolab-format specification is mandatory and binding for all Kolab-clients,
and any particular client's behaviour is irrelevant.
> This is in no way "loosening" the specification,
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!
> So you're saying with absolute certainty that the Thunderbird and
> Lightning APIs definitely do not offer RFC3339 parsing, nor timezone
> management?
>
> So you're 100% certain that Evolution does not offer APIs for tz support?
Georg, IMO this is completely the wrong approach: 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", hence you are introducing a significant hurdle for other
PIM-Clients to become Kolab-Clients and for existing Kolab-Clients to
support version 2 of the Kolab-format, if KEP2 in its current state woud
become that v2.
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. 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.
But, as I wrote above, it simply makes no sense for any of those clients to
offer a RFC3339-parsing API, as Plug-ins mainly just pass and receive
iCal-objects (for all kinds of events): how they are dissected somewhere
inside the PIM-client is not and must not be of the plug-in's concern
and/or business. This seems to be MS-Outlook's approach as well, from what
I extracted out of Joon's and Shawn's statements.
The hassle starts when one intents to do more in/from a Plug-in than the
plugin-API-developers have anticipated (this is an generic statement!),
once again experienced in the evolution-kolab project (only this is
specific to evolution) and before many times with Synckolab (e.g. no IMAP
annotations accessible through Thunderbird's IMAP-API).
In those cases one briefly considers extending or altering the API, but
while that option exists in theory (well, not for MS-Outlook), it is
practically infeasible in all cases, due to the lack of resources (time,
money, humans; and the efforts of maintaining that code in the future) as
well as the reluctance of upstream to accept changes which only accommodate
a single plug-in in the first place.
I split my reply in two parts in order to keep some topics apart, especially
the important topic "central in-format TZ-data vs. individual local
TZ-databases".
Part 2 will be following immediately.
Regards
Florian
More information about the format
mailing list