PIM-Item Relations / Categories
mollekopf at kolabsys.com
Wed Jun 6 16:03:45 CEST 2012
On Wednesday 06 June 2012 15.18:10 Georg C. F. Greve wrote:
> On Wednesday 06 June 2012 11.54:56 Christian Mollekopf wrote:
> > Maybe we have to... Maybe categories can also indeed be useful for
> > calendars,
> Generally speaking, categories can be useful for all kinds of object types,
> and one use case would be to present all emails, address book entries,
> calendar events, todos and notes that are part of one category.
True, it's just a tag without any concept attached.
For me the question is more how far we should go in bastardizing those tags.
Supporting hierarchies kinda works, because the tag is still usable even if
the editor doesn't have support for it (it just becomes a
"/supercategory/subcategory" tag). Of course renaming of categories is fairly
broken in such a case but IMO we could live with that.
IMO such "custom" features hurt interoperability more than they help though
(given that we anyways will have more powerful ways to organize PIM-Items).
If we even support color configurations we open a whole new can of worms,
because those config files need to be kept in sync with the categories as well
(i.e. for moves and renames of categories).
So as far as possible I'd like to treat categories as what they really are,
plaintext tags, but don't know to what extent that is acceptable. So IMO we
shouldn't add colorconfiguration and hierarchies just because others did, or we
used to have it, because it's fundamentally broken. If there is nevertheless a
real need for it, I'm sure we'll figure out a solution for all problems (I'm
just asking to think twice, which you guys might have already done of course
With PIM-Item relations we can do all that stuff such as color-configuration and
tree hierarchies in a clean way, so that might provide us with an alternative
At least outlook 2007 and ical don't support subcategories, so from that POV
we don't need to be compatible with them. Both support color-coding of
> Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format