[Ietf-calsify] Re: What's wrong with more radical simplification?
reinhold at kainhofer.com
Fri Feb 11 09:30:25 PST 2005
On Friday 11 February 2005 18:04, Helge Hess wrote:
> On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> > Helge Hess wrote:
> >> If you have some standard you basically always loose information
> >> since you need to find a viable common denominator.
I would argue to the contrary. What I like so much about iCalendar is that it
defines a way to do almost anything you might ever want to do. So when you
implement a new feature in your calendar application, most of the time,
iCalendar already gives you a format how to store this feature in an
iCalendar object (for drag'n'drop, invitations, even storing). So you don't
have to cook your own soup, but instead can use a standard which other
clients (that implement a similar feature) can also understand.
I think it basically boils down to the two views of standards:
1) A standard should describe what every application MUST implement. If an
application wants to do something more, it's on its own. ("lowest common
2) A standard gives a suggestion how an application might implement any (even
very exotic) feature. No application will ever implement full support for
every little detail of such a standard, but if it implements one feature, it
can be sure that any other application that implements a similar feature will
be able to reuse the data.
it seems most people here think that a standard is just for those parts that
every application must implement (i.e. every detail of a standard needs to be
supported by an application).
However, what I like so much about iCalendar is that it gives you a
standardized way for lots of advanced features.
> You have the assumption that fixing the clients is an easy and viable
> task. I had the impression that currently rrules can represent every
> recurrence model which was supported by the initial protocol creators.
I think it was meant to be able to describe every possible combination one
might ever need. Anything else wouldn't make sense, because again it would
lead to fragmentation, since one would need to invent a new solution if an
application has needs that are not covered by a limited standard. And then
one can be sure that interoperaility between two applications that both
support such an advanced feature will never work.
> This in turn makes it very complex and forces everyone to implement all
> the rrules of the others (and in practice nobody does that which makes
> rrules not interoperable).
> But people suggested that I might be wrong on how compliant current
> clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really
> support 100% of the currently specified iCalendar rrules?
No, at least korganizer / kontact doesn't. AFAICR, BYSETPOS is not correctly
handled. The GUI of korganizer or kontact might not suggest it, but our
libkcal library does in fact support almost the whole specification.
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/7bc4c12b/attachment.bin
More information about the Ietf-calsify