Re: [sup-devel] sup-server revisited

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] sup-server revisited
Date: Wed, 23 Feb 2011 15:53:23 -0300	[thread overview]
Message-ID: <1298486753-sup-2845@alvh.no-ip.org> (raw)
In-Reply-To: <1298485426-sup-5530@masanjin.net>

Excerpts from William Morgan's message of mié feb 23 15:43:34 -0300 2011:

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

I like this, except the part that thread_labels = union(states).  It
doesn't work correctly for "attachment" for example: it makes it look
like the whole thread "has attachments" which doesn't make sense.  The
user really needs to have a way of telling messages that really have
attachments from ones that don't.

Also, you said upthread that Heliotrope was going to provide ways to
break threads and form new ones from pieces.  I badly want this feature
:-)  (I haven't checked Heliotrope out yet).

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

Agreed.  Someone mentioned some weeks ago that "undo" badly messed up
labels that you're now separating as "state" (again, attachment).  Seems
like the current proposal fixes that problem.

-- 
Álvaro Herrera <alvherre@alvh.no-ip.org>
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel