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

List:       kde-pim
Subject:    Re: [Kde-pim] icaldir Proposal
From:       Mark Bucciarelli <mark () easymailings ! com>
Date:       2006-02-08 14:46:45
Message-ID: 20060208144644.GA2656 () rabbit
[Download RAW message or body]

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?

What does it do if it opens an ical file was created by KOrganizer?  Fail?
Overwrite the PRODID?

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).

> 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.

> 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.

> 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?

m

_______________________________________________
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]