[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-11-29 8:16:27
[Download RAW message or body]

On Friday 29 November 2002 00:19, David Jarvie wrote:
> 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.

Have a look at libkabc nad KAddressBook and how it handles custom properties. 
This is the way I would also consider useful for libkcal.

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

That's exactly what I meant. Are you sure about the QCString argument? Does 
iCalendar define the property names to be something different than utf8?

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

In many cases custom properties aren't necessary, because the same information 
can also be stored using the standard properties. If that is possible it's 
certainly preferable because other programs get a chance to also handle the 
information.

An additional problem is that in many cases custom properties store 
information of the view, not the document. For example if you store a screen 
position in the calendar file, you might get weird results, if you open the 
file on another computer with a smaller display. For this kind of information 
it's better to store them locally. KOrganizer even has a class for that 
(DocPrefs). Maybe we should move this to libkcal.

Finally, have you ever tried to load a file containing custom properties in 
KOrganizer and save it again? All custom propeties are lost. Ok, this is a 
bug, but I'm not sure that other programs don't behave the same.

-- 
Cornelius Schumacher <schumacher@kde.org>

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