NEW KEP: Color configuration storage for resources and categories (KEP #12)

[Jeroen van Meeuwen (Kolab Systems)]

Georg C. F. Greve wrote:
> Dear all,
> 
> A new KEP has just been released into the public drafting & review process:
> 
> 	KEP #12: Color configuration storage for resources and categories
> 	http://wiki.kolab.org/User:Greve/Drafts/KEP:12
> 

A few comments:

- I fail to see what creating a new annotation /vendor/kolab/color adds over 
using the /vendor/kolab/folder-config defined in KEP #9, that can hold:

  {
    (...snip...)
    'color': <value>
    (...snip...)
  }

I do however see the trade-off of adding yet another annotation; As mentioned 
before, valid annotations that the server accepts need to be shipped to the 
server platform in a static list.

Adding new, changing existing and removing old annotations requires packaging 
up the changes across a large number of native and packaging platforms, 
consumer documentation and intervention on consumer systems all of which seem 
relatively easy to circumvent by not as lightly defining as many annotations.

That said, if it is desirable to provide consumers with the option to opt-out 
of providing the capability to use coloring per folder through the 
/vendor/kolab/color annotation (by removing the /vendor/kolab/color entry from 
/etc/imapd.annotations.conf), I think it needs to be documented as such in the 
KEP, including requirements or guidelines for clients on how to handle such a 
scenario.

Perhaps a little out-of-scope for this KEP, but I would recommend seeking a 
solution in which the server presents the client with perhaps something like a 
CAPABILITY response on the level of Kolab compatiblity, rather then using a 
attempt-and-fail-silently, or (client-side) configuration item approach. I 
would recommend including in this KEP however, that it does NOT specify how 
the client would/should/could be made aware of the required server 
capabilities.

Perhaps such level of option value (disabling / enabling the coloring 
configuration feature) should extend to the category display color defined as 
XML objects as well.

- Furthermore, I would like to know how a color annotation would apply to the 
contents of a folder with /vendor/kolab/folder-type mail.

- Also, the use of the phrase """hexadecimal triplet of six characters""" 
seems confusing in that XXXXXXYYYYYYZZZZZZ could arguably be considered a 
triplet of six characters. Perhaps sticking to the 6-digit hexadecimal number 
is more appropriate, and perhaps including a statement on 3-digit hexadecimal 
web colors is appropriate as well.

- There's a 'the the' in the /vendor/kolab/color rfc 5464 annotation section.

- Would you please consider indenting the line that is in one of the example 
XML objects for category definitions;

    <name color="XXXXXX">ConfCall</name>

one more level for clarity / readability?

- In the section "Client behaviour", if at all appropriate, could we expand 
the following phrase:

"""Authors of other clients are strongly encouraged to default to the 
Microsoft color table[5] to ensure consistency across clients."""

to use SHOULD instead of "are stronly encouraged"?

- I would also like you to consider rephrasing:

"""Some Kolab clients such as Outlook[6] provide means for color-coding all 
kinds of resources, including email, so Kolab should support this as well."""

as it sounds to me like "desparately seeking to imitate Outlook (...)", and I 
think it only partly reflects the truth.

I think perhaps a phrase such as:

"""Most groupware clients provide the means to color-code all types of 
groupware objects, including email (with flags), (...), but no client 
currently shares this information with other client (instances) through IMAP, 
(...) and to be able to provide a level of cross-platform and cross-client 
consistency (...)""" - or somesuch?

- There's a small inconsistency in the rationale for "Colors per category";

It seems that "parsing the entire (resource) tree" is being used as the 
terminology to both indicate "parsing all the contents of the objects in a 
resource tree" in order to discover what Categories have been defined, as well 
as "parsing the resource tree" - and not the contents of all objects in every 
"branch of the tree" (i.e. folder).

I think the tradeoff for/against using annotations to store categories and 
color configuration for said categories is;

- using annotations won't scale linearly with the potential number of 
categories defined and configured, ...

    but then again nor does scanning all object contents throughout the 
resource tree (rationale for moving forward),

    whereas a /vendor/kolab/folder-type config can contain as many XML objects 
of type 'category' as one needs (rationale for current proposal).

That said, however, it seems we are not using /vendor/kolab/folder-type 
configuration, and all clients are going to be required to scan all objects in 
any position in the tree in order to allow them to recognize that potentially 
an object contains configuration. While admittedly KEP #9 implicitly (should 
be explicitly) allows for XML objects of type configuration to be stored in 
all folders but those of type 'mail', it does not take in to account that 
perhaps a RFC(2)822 message header could be used in order to be able to 
quickly find the messages containing configuration type XML objects.

- KEP #9 specifies a configuration XML object is supposed to look like:

 <?xml version="1.1" encoding="UTF-8"?>
 <configuration version="2.1">
   <!-- Common fields -->
   <uid>(string, no default)</uid>
   <creation-date>(datetime, no default)</creation-date>
   <last-modification-date>(datetime, no default)</last-modification-date>
   <type>(string, no default)</type>
   
   <!-- Type specific fields -->
   ... type specific fields ...
 </configuration>
For some reason, we are not using this.
- In the example XML object of type category, would not the top-level name 
attribute be used to compose the uid from?

- Also, how many top-level name attributes may exist in a single category XML 
tag / XML object?

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110907/a7626c58/attachment.html>