[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] icaldir Proposal
From:       "David Jarvie" <lists () astrojar ! org ! uk>
Date:       2006-02-08 17:19:49
Message-ID: X_O3bD.A.xM.Svi6DB () s1 ! uklinux ! net
[Download RAW message or body]

On Wednesday 8 February 2006 14:46, Mark Bucciarelli wrote:
> On Wed, Feb 08, 2006 at 01:09:25PM -0000, David Jarvie wrote:
> > I want the application name and version to remain in the PRODID. If you
want
> > to put the icaldir version in PRODID as well, I don't mind. Currently
KAlarm
> > uses the PRODID string to distinguish KAlarm calendars from other ones,
and
> > to identify which version of KAlarm wrote the calendar. This is
necessary
> > because it uses various special property values to hold alarm
attributes. It
> > needs to know which version of KAlarm wrote the calendar so that it can
> > provide backward compatibility. The KAlarm version is of course
independent
> > of the ical version.
> 
> How does KAlarm behave when it opens an icalendar file that was written by
an
> older version of KAlarm?  Does it upgrade all events in the file to the
new
> property names?  Or do you maintain compatibility for all previous
flavors?
 
It upgrades all events to the new version.
 
> What does it do if it opens an ical file was created by KOrganizer?  Fail?
> Overwrite the PRODID?

It will attempt to use the file, but it won't necessarily work particularly
well - I've never actually tried it out. Currently, it always overwrites the
PRODID whenever it writes back to any file, but from what has been said in
this thread, perhaps that policy should be reconsidered.

> Hmmm, multiple apps, multiple app versions, multiple spec versions, one
PRODID
> field and one VERSION field per calendar.  This needs to be fleshed out
some
> more.
> 
> Maybe the way to address this is to expand the PRODID or VERSION property
> definition.  Or stick a new property in the object file itself (Ingo's
> suggestion).

A new property might well be a good idea.

> > I'm sceptical about using the tz database and ignoring VTIMEZONE
objects.
> > There is no guarantee that a VTIMEZONE imported from another system will
use
> > an identical definition of the time zone to that held in the tz
database.
> 
> True in theory, but I'm not sure it's true in practice.  Using a time zone
> registry is _very_ simplifying stroke, because it removes one source
> inter-file dependencies as well as a good chunk of code.

I agree that it would be very good to scrap VTIMEZONE handling and simply
use the tz database. I'm arguing on the basis that the ical spec still
defines VTIMEZONE and doesn't state that definitions must be identical to
the tz database, so therefore we should implement it.
 
> > Any discrepancies could result in wrong event times, etc. 
> 
> Then their Perl script that converts stuff fails and they use the old
spec.
> No problem.

If you mean that there will be a checking mechanism to decide whether the
VTIMEZONE defines an identical time zone to that held in the tz
 database, and if not, to use the VTIMEZONE definition, then that's fine.

> > Until such time as the ical spec says that the tz database is the only
> > permissible source of time zone definitions, and therefore scraps the
> > VTIMEZONE object, we can't just ignore VTIMEZONE. At least, not in
calendars
> > imported from elsewhere.
> 
> Do you have a real-world example?

No, but sod's law says that some system and some application somewhere uses
at least slightly different definitions. Which may not matter most of the
time, but...

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]