From: gsf@fruct.us (Gabriel Sean Farrell)
Subject: [sup-talk] Persistence between IMAP clients
Date: Tue, 5 Feb 2008 16:03:42 -0500 [thread overview]
Message-ID: <20080205210342.GA4870@manheim.library.drexel.edu> (raw)
In-Reply-To: <1202149761-sup-2303@tangerine.lanl.gov>
On Mon, Feb 04, 2008 at 11:46:16AM -0700, John Bent wrote:
> Excerpts from Gabriel Sean Farrell's message of Mon Feb 04 08:12:21 -0700 2008:
> > Is there a way to persist the labels applied from an instance of sup
> > IMAPing from one machine to another instance on another machine? I
> > check my mail from four different computers on a regular basis, and I
> > haven't figured out, for example, how to delete emails when checking
> > with one machine and see them as deleted (that is, *not* see them in my
> > inbox) when checking with another.
> >
> This isn't really answering your question but ... the reason I use sup is
> because I can then use multiple computers to check email but have a
> persistent view (exactly like what you want). However, the way I do this
> is not by figuring out how to maintain consistent labeling state across
> the multiple instances but rather by only actually running sup from one
> machine. I then can check email from multiple computers by always ssh'ing
> to that machine. That's why I like sup: it's console based and lends itself
> perfectly to this approach.
>
> Even though this probably wasn't the answer you were looking for, I fear it
> might be the best one you get. sup isn't designed to actually modify any of
> your existing mail folders. It only reads them and then maintains its own
> external state. So, for example, you can't configure sup to delete emails from
> an IMAP server. What you can do is configure an external program like
> fetchmail to pull the emails (and delete them from the IMAP server) and put
> them into a local mbox on your machine which sup can then read. That might
> work for you; however, you'll splinter your emails. Emails which are read on
> one machine won't appear on your other three. What you want is for sup to just
> read from the IMAP server and leave them there and then for the four multiple
> instances of sup to share their state with each other. But they have no
> mechanism for doing so - they'd need some server somewhere to help them and
> they'd also need a bunch of code to implement that functionality. You could
> try to get that functionality transparently by using a distributed file system
> shared across the four machines in which you keep your .sup folder. That
> should work (unless maybe there is binary data kept in the .sup files and you
> have endian incompatibility across the four machines). You could try to
> approximate the shared file system thing by using something like cvs or git,
> but that would be a big silly hassle. Unless anyone else thinks of something
> better, I think the ssh approach is your best bet.
>
> My only remaining limitation with the ssh scheme is that my primary machine is
> my desktop so I am not able to slurp down a bunch of new emails onto my laptop
> and work on them from the plane... (the answer of course is to make the laptop
> be the primary machine but that doesn't work for a couple of other various
> reasons).
Thanks for the thoughtful response.
I have checked my mail over ssh for a long time (with mutt), but within
the last year I've come to really appreciate IMAP. I use a combination
of ssh and screen to work on all of my servers, but it's nice to be able
to avoid it when checking email on a spotty connection (no more network
stuttering while I edit a response!). Also, attachments are easier to
deal with. An IMAP setup allows me to check in with the client on my
phone occasionally as well.
In short, I like to have one place that handles the storage (which is
why I don't use POP3) *and* the status of my email. It occurs to me now
that Sup, when used with IMAP, follows a paradigm wherein the status
(maybe "metadata" would be a better word) for each email is shared
between the server and client. Maybe my preference is due to
assumptions from my years of mutt use. After all, the difference
doesn't matter if you only use one client. It is the reason Sup doesn't
play well with others, however, or with other instances of itself.
Gabriel
next prev parent reply other threads:[~2008-02-05 21:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 15:12 Gabriel Sean Farrell
2008-02-04 18:46 ` John Bent
2008-02-05 21:03 ` Gabriel Sean Farrell [this message]
2008-02-05 16:42 ` William Morgan
2008-02-05 19:12 ` Magnus Therning
2008-02-05 19:51 ` William Morgan
2008-02-05 21:11 ` Gabriel Sean Farrell
2008-02-05 22:02 ` William Morgan
2008-02-06 22:37 ` Gabriel Sean Farrell
2008-02-07 8:45 ` Marcus Williams
2008-02-07 18:12 ` William Morgan
2008-02-07 20:12 ` Gabriel Sean Farrell
2008-02-07 21:09 ` Marcus Williams
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=20080205210342.GA4870@manheim.library.drexel.edu \
--to=gsf@fruct.us \
/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