Small extension to the annotate proposal
Stuart K. Bingë
omicron-list at mighty.co.za
Mon Jul 12 12:46:05 CEST 2004
On Tuesday, 29 June 2004 10:41, David Faure wrote:
> To make the proposal more precise:
> We currently have
> /vendor/kolab/folder-type where value.shared is set to mail, event,
> journal, etc.
I'd like to see the format updated to include client-specific annotations, as
sub-annotations of /vendor/kolab, e.g. /vendor/kolab/o-blah for
Outlook, /vendor/kolab/k-blah for Kontact and /vendor/kolab/h-blah for Horde
(as we do for additional client-specific XML tags).
Why I ask is that I actually require this functionality for Horde, in order to
solve a problem I've been having. Horde has the concept of "shares"
internally, that act as groupware object containers within each Horde
application - my problem is that I need to map specific IMAP groupware
folders to their corresponding Horde shares. An elegant solution to this is
to create an annotation such as /vendor/kolab/h-share-uid with value.priv set
to the UID of the corresponding share - in this way I can easily track the
IMAP folder <=> Horde share mappings.
As an aside, would it make more sense to use "vendor.kolab.blah"
sub-attributes of the /vendor/kolab annotation, instead of an annotation tree
under it? Both schemes seem pretty interchangable, however it may make more
logical sense to use attributes of an annotation to describe whatever
variables need describing, rather than storing them all in an annotation tree
(I'm thinking in terms of XML - /vendor/kolab describes the parent object,
and each vendor.kolab.XXX attribute describes a property of the parent
This is definitely being picky, but it seems rather redundant of the
ANNOTATEMORE extension to include provisions for both schemes. Please ignore
this if you want to - I have no problems using either scheme, I've just been
thinking about this :-)
> I like the idea of adding
> /vendor/kolab/storage-format where value.shared would be "xml 1.0"
> (referring to the kolab xml storage version 1.0". This would allow to set
> it to 2.0 in case of major changes later, and it would also allow values
> like "ical 1.0" or "vcard 1.0".
I would have to agree to this being added. More descriptive annotations are
good, in that if I don't know how to handle a specific folder I can then
simply ignore ("preserve") it, rather than making (possibly incorrect)
assumptions as to the folders' contents.
Code Fusion cc.
Office: +27 11 673 0411
Mobile: +27 83 298 9727
Email: s.binge at codefusion.co.za
Tailored email solutions; Kolab specialists.
More information about the format