Reformatted excerpts from Miles Pomeroy's message of 2008-04-28: > > This is part of the sup philosophy. It treats mail sources as dumb > > stores, and doesn't try to change them. > > If this is part of sup philosophy then I'm assuming that it's not > going to change. Can someone explain to me why this is a good thing? I > use multiple computers and would like to use multiple clients to check > my email, but this philosophy seems to only allow for one computer, > one client.
That's a good question and it deserves explanation. There are two issues. The first is simply pragmatic. Sup is never going to be able to compete with programs like Mutt in terms of operations like "open up a mailstore of some format X, and mark a bunch of messages as read, and move a bunch of messages to this other mailstore." That's a tremendous amount of work to get right, get safe and get fast, and Mutt's already done it well, and I sure don't want to have to reimplement it. The other issue is more philosophical, and that's that I ultimately view Sup as more of a service than as a MUA (even though it currently only has itself as a client and has been masquerading as a MUA for its entire life). I think the things that make Sup interesting and useful are the indexing and the flags, and those are things that don't translate to known mailstores at all. So in terms of multi-computer access, I would rather invest time in building up a sup-server program (which has been discussed here before, and I'm coming around to the idea, especially in light of things like Thrift) or a sup webserver (which currently exists in a proof-of-concept form) than to invest time in things that don't play to Sup's strengths. That said, if someone handed me a bunch of patches that does write back read/unread status to mailstores of whatever formats, I'd be more than happy to incorporate them. I'm just personally not going to spend a lot of development time on those features. -- William <[EMAIL PROTECTED]> _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
