NEW KEP: Color configuration storage for resources and categories (KEP #12)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed Sep 7 14:37:05 CEST 2011
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
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:
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
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
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;
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 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 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"?>
<!-- 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 ...
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?
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format