From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] Gmail IMAP with sup
Date: Tue, 29 Apr 2008 10:45:28 -0700 [thread overview]
Message-ID: <1209490287-sup-9950@south> (raw)
In-Reply-To: <C1A07365-2CDE-4C1A-9416-9B4C125610D4@gmail.com>
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 <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2008-04-29 17:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 22:30 Miles Pomeroy
2008-04-16 1:46 ` Jeff Balogh
2008-04-28 16:25 ` Miles Pomeroy
2008-04-29 17:45 ` William Morgan [this message]
2008-04-16 15:16 ` William Morgan
2008-04-16 15:30 ` Kendall Grant Clark
2008-04-16 17:15 ` Marc Hartstein
2008-04-16 19:02 ` Chris Warrington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1209490287-sup-9950@south \
--to=wmorgan-sup@masanjin.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox