Re: [sup-devel] sup-server revisited

From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] sup-server revisited
Date: Wed, 23 Feb 2011 18:43:34 +0000	[thread overview]
Message-ID: <1298485426-sup-5530@masanjin.net> (raw)
In-Reply-To: <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com>

Reformatted excerpts from Nicolas Pouillard's message of 2011-02-23:
> I would not go for "labels on threads" only, here is a list of labels that
> are more message based than thread based: unread, starred, draft, sent,
> attachment. And while it would make sense to have special cases for those
> this also prevents from user defined per message labels.

One of the major goals of Heliotrope is to formalize this type of thing and to
implement it correctly. Here's the model:

- Individual messages have "state", including unread, starred, and all the
  other things you've mentioned.
- Threads have "labels", which are user-defined.
- Message state is mapped onto thread labels by taking the union of the states
  of all the messages in a thread. E.g. if one message is unread, the entire
  thread has the unread label.
- Sup maintains that mapping for you.
- The user can set (some of) the state of a particular message.
- The user can set the labels for a thread, but can't create labels that have
  the same name as a message state.
- The labels of a thread match all messages in a thread at search time.

Sup conflates these things, maintains labels on messages only, and does some UI
stuff to make it seem like they apply to threads. It's easy to find corner
cases where you get weird behavior.
-- 
William <wmorgan-sup@masanjin.net>
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel