Mailing List Archive

On Tue, 2012-05-01 at 22:55 +0000, Daniel Pocock wrote:
>
> If I understand correctly, the iCal spec allows any arbitrary field name
> to be defined in an event or todo/task item:
>
> http://tools.ietf.org/html/rfc2445#section-4.8.8.1
>
> E.g. someone could define a field called `X-Budget' and presumably put
> in some numeric currency value for each task
>
> Can anyone comment on the practical issues of supporting this in DAViCal
> and Lightning when they are used together? Are there any examples of
> such custom fields already implemented?
>
> Some of the specific things that come to mind:
>
> - adding the field to the windows in Lightning
>
> - ensuring that DAViCal will persist the field name and value in the
> database - does the DB support arbitrary attribute/value pairs, or must
> a new column be created for each X-<something>?
>
> - making some kind of user accessible report based on custom fields (or
> even reporting against the standard fields)

Hi,

DAViCal only internally parses fields it might use, and does not
construct iCalendar resources itself, but instead returns the data it
originally received. Also, DAViCal targets the new, revised & improved
iCalendar specification which is RFC5545.

There are some caveats to that:

* In certain circumstances DAViCal returns an 'obscured' event, where
the actual data has been replaced with 'Busy' and other placeholders.
These copies will NOT contain any X- properties.

* When the event is a meeting it may be processed and copies sent to the
calendars/inboxes of other attendees with corresponding status about
this rewritten in the original. These modifications should retain any
X-PROPERTIES unmodified.

* On output DAViCal will force any line-endings in a non-compliant
iCalendar resource to all end with CRLF. No properties or values will
be harmed in this process. [1]

As you can see, all pretty minor stuff.

So if you wanted to use a client which added an "X-Budget" field then
DAViCal would neither know nor care, returning it to you invariant. The
hard work is going to be in Lightning.

If you wanted to parse and store that field, catching changes when it
was modified in DAViCal, then you could do some minor processing in the
'log_caldav_action' hook as well.

Cheers,
Andrew.


[1] Unless it's a bug, of course.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Necessity is the mother of documentation
------------------------------------------------------------------------