Did you all forget we already had this discussion? Here's the outcome we had then, and here's the outcome we're having now:
NOBODY DUCKING AGREES. Which is fine. I'm on the gmail side of threading. I read this list mostly in Mail, which has a flattened thread similar to gmail's, but without the nice thing of doing away with the mailbox listing and instead showing the conversation view. Anyhoo, here's my suggestion: We implement full on, references-based, jwz-style threading. What? Why? Well, this is the most complete interface to threads. The others are a subset of this. With that, I suggest that: **The threading mechanism be pluggable.** With threading being handled in a plugin, we can fix the thread however we want on the backend, and make use of the powerful fully threaded UI that ships by default. Should the UI also be customizable? Probably, but the fact is that UI programming is fussy, and if you just want to rethread messages, performing data transformation on the backend is a lot simpler then mucking with user interaction and outlets and responders and delegates and whatnot. Having the references-style threading be the default is also a good idea because it's simpler to flatten a tree than to branch a list. I specially liked the suggestion of flattening sub-threads that are linear. Preferably, fuzzy flattening of them, so that it happens even when they're not completely linear but mostly so. This is a true major win. Other things that plugins could handle is splitting and merging threads, gmail-style subject-based threads, and even nested threads that split on fuzzy subject changes. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
