Hey all,
I thought I'd ask this on sup-devel, since you guys have been thinking
about email organization and "a better mutt" sounds pretty awesome ;).
Sorry if it's too far off topic.
Since email can have multiple parents [1], why does everyone make
threads trees rather than directed, acyclic graphs (DAGs)? DAGs seem
really common for version control systems, and completely missing for
email clients, even though the inheritence structure is identical.
For example, here's a slice from the recent be-devel list as a graph:
...............
| *-|-\ | | Mon Jan 25 W. Trevor King Re: Project releases
| * | | | | Sat Jan 23 Gianluca Montecchi Re: Project releases
| | | | t | | Sat Jan 23 Gianluca Montecchi Re: Project releases
| *-|-|-|-\ | | Fri Jan 22 Ben Finney Re: Project releases
| | | * | | | | Fri Jan 22 W. Trevor King Re: Project releases
| | | *-/ | | | Thu Jan 21 Ben Finney Re: Project releases
| * | | | | | Thu Jan 21 Gianluca Montecchi Re: Project releases
*-|-|-/ | | | Thu Jan 21 W. Trevor King Re: Project releases
...............
^--- inheritence graph.
You can see that Ben's Fri message and my Mon message both have two
parents.
On a sup-specific level, problems with the graph (vs. tree) is that it
may make threads too 'sticky'. With your thread-centric approach,
you'll want to break threads when the topic mutates too far from the
original, and that could be difficult for meshy-graphs. Perhaps you
will want to leave the sup guts unchanged, tack on an optional graph
view, and add an 'other-parents' option when browsing from messages
with multiple parents.
On an implementation level, I've got the above graph browser going
in python/curses, so it should be easy to port to ruby/curses.
Thoughs?
Thanks,
Trevor
[1] RFC 2822, section 3.6.4, http://www.faqs.org/rfcs/rfc2822.html
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields.
--
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
Attachment:
pgp2HJwtbdDXV.pgp
Description: PGP signature
_______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel