Small extension to the annotate proposal

[Stuart K. Bingë]

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

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.

Regards,

-- 
Stuart Bingë
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.
http://www.codefusion.co.za/