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

List:       kde-pim
Subject:    Re: [Kde-pim] libkcal amendments for email alarms
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2002-11-28 23:19:48
[Download RAW message or body]

On Thursday 28 Nov 2002 6:57 pm, Cornelius Schumacher wrote:
> On Thursday 28 November 2002 13:44, David Jarvie wrote:
> > On Thursday 28 Nov 2002 8:02 am, Cornelius Schumacher wrote:
> > > Please don't add Kalarm specific code to libkcal. If you really
> > > need custom parameters please implement a generic way to access
> > > these. Something like "setCustomParameter( const QString &app,
> > > const QString &key, const QString &value )".
> >
> > I'm not sure about the 'app' parameter - is it necessary to have the
> > application specified at all? When reading from the calendar, any
> > custom properties which were set for other applications would be
> > updated in the Alarm instance but would then simply be ignored by the
> > client application. When writing to the calendar, custom property
> > values in the Alarm instance should only exist for the client
> > application, so no properties specific to other applications should
> > be written. If you insist on a test for the application identity,
> > presumably we would have to use
> > kapp->aboutData()->appName() ?
>
> The app parameter is only to define a clean namespace. Otherwise you
> could accidently overwrite parameters from other apps. We should also
> make sure that unknown custom parameters get written back.

I'm afraid that I still don't understand how this would be used.

> In addition to that I wouldn't like to see KAlarm specific code in
> libkcal. libkcal should stay a generic iCalendar library. Why don't you
> store the data in a generic way?

OK, perhaps the following will satisfy that requirement - I can't think of any 
other way:

The Alarm class would hold a QMap<QCString, QString> of custom properties, 
without actually knowing their meaning. ICalFormatImpl::readAlarm() would 
read in all the custom property name/value pairs and set them into the Alarm 
instance. The application would read any custom property values which it was 
interested in from the Alarm instance, via a 'QString customProperty(const 
QCString *key) const" method. The application would set any custom properties 
via 'void setCustomProperty(const QCString &key, const QString &value)', 
which would simply add/substitute the specified key/value pair into the Alarm 
instance's map. Then ICalFormatImpl::writeAlarm() would read the complete 
list of custom properties from the Alarm instance using 'QMap<QCString, 
QString> customProperties() const' and write them all to the VALARM 
component.
The application would probably also need either a method to initialise the 
custom properties map to empty, or to delete a specified custom property from 
the Alarm.

> Are you sure that you need the custom property. Storing custom data in
> iCalendar should ve avoided wherever possible. This isn't good for
> interoperability. You can always store the data separately and
> reference it by the unique ids.

I don't see why custom properties should harm interoperability any more than 
storing data in separate files. After all, RFC2445 allows custom properties, 
and they shouldn't interfere with any application which doesn't know how to 
interpret them. For such an application, the information is simply missing, 
just as if it had been written into a separate data file. And I'd much rather 
have all the data in a single calendar file than have to mess about with a 
second file. Obviously what I say applies primarily if the custom properties 
contain only a small amount of data - the balance might tip towards a 
separate data file if there was a lot of extra data to store.

-- 
David Jarvie
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://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]