[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-09 11:53:36
Message-ID: 7NE1IB.A.NoD.H5y6DB () s1 ! uklinux ! net
[Download RAW message or body]

On Wednesday 8 February 2006 20:35, Mark Bucciarelli wrote:
> On Wed, Feb 08, 2006 at 05:19:49PM -0000, David Jarvie wrote:
>
> > 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.
>
> Yeah, I think that violates the RFC. Unless you interpret file
> creator liberally.
>
> > > 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.
> 
> The root cause of this app versioning problem is custom ical properties.
> 
> KArm does this too, except it is not as smart as KAlarm--it does no
> version tracking.
> 
> As the spec stands, it is possible that the icaldir is on a NFS mount
> share and two users have two different KAlarm versions. It is possible
> that some objects are written with KAlarm version 1 and some w/ version.
> 2. Then multiple by KArm + KOrganizer + iCal, etc it becomes an
> exercise in combinatorics.  Not good.

Perhaps the application and version information should be written into every
individual incidence, rather than into the calendar as a whole. That would
make it easier to mix data from different applications within the same
calendar.

Up to now, KAlarm has always been written as a purely personal alarm
scheduler, with its own private calendar files which are assumed not to be
shared with other applications or even other users. As it happens, I am
currently working on implementing resource access for KAlarm, so what you
say is apposite. I hadn't considered the need for forward compatibility, to
cover two different users using two different versions of KAlarm. Perhaps if
KAlarm encounters a calendar file written by a different version of KAlarm,
it may need to treat it as read-only to avoid data loss due to
misinterpretation if it updates events in that calendar, unless in the case
of an earlier version the user chooses to upgrade the calendar to the
current version.

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