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 _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
