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

[Georg C. F. Greve]

On Wednesday 07 September 2011 13.37:05 Jeroen van Meeuwen wrote:
> - 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:

As discussed separately, and discussed in

	http://kolab.org/pipermail/kolab-format/2011-September/001469.html

there is no such annotation defined in KEP #9, so using it is not an option, 
creating it would require an additional KEP that would have to be completed 
before we could close this particular KEP.

So I'll leave this part as is pending the outcome of that discussion.


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

I agree both with this being an interesting use case in general -- the ability 
to "turn off" functionality -- as well as the need to document it.

Maybe for this particular case it is not the most critical functionality to 
have, but then it is sometimes hard to tell when certain functions do or do 
not make sense in this way.


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

Agreed on both points that it would be useful, and that it is outside of the 
scope of this KEP.


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

That will depend upon the client, obviously.

Ultimately, allowing color coding of mails is something that Outlook already 
does, even though the way this feature currently behaves would seem more like 
being category based, I could see clients making use of colour in this area, 
as well, e.g. for marking folders that are particularly important in the 
folder list.


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

Okay. Will try to make that less easily misunderstood.



> - 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"?

Agreed.


> 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?

Will work with that, thanks!

Will also try to work in the other points raised.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110928/28092d08/attachment.sig>