Subject: [sup-talk] Persistence between IMAP clients

From: [email-masked] (Gabriel Sean Farrell)
Date: Mon, 4 Feb 2008 10:12:21 -0500

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.  

Gabriel

---

From: [email-masked] (John Bent)
Date: Mon, 04 Feb 2008 11:46:16 -0700

> 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).

John

---

From: [email-masked] (William Morgan)
Date: Tue, 05 Feb 2008 08:42:03 -0800

> inbox) when checking with another. 

There is no good way to do this. There are bad ways (you can dump all
your labels with sup-dump, send them over, and apply them with
sup-sync).

Sup will probably never work well in this kind of setup.

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Magnus Therning)
Date: Tue, 05 Feb 2008 19:12:10 +0000

> Sup will probably never work well in this kind of setup.

Would it be possible to simply use unison to synchronise the machines?
As long as you can make sure to avoid conflicts and you can make sure
system-specific settings (such as file locations and server settings)
are the same it /could/ work.  Please note that I've never tried it with
sup, but other MUAs have worked fine this way.

/M

-- 
Magnus Therning                             (OpenPGP: 0xAB4DFBA4)
magnus?therning?org             Jabber: magnus?therning?gmail?com
http://therning.org/magnus

What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
     -- Daveman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080205/27dda927/attachment.bin

---

From: [email-masked] (William Morgan)
Date: Tue, 05 Feb 2008 11:51:08 -0800

> Would it be possible to simply use unison to synchronise the machines?

If ~/.sup/sources.yaml and ~/.sup/ferret are both synchronized, that
should basically work. Of course, unless Unison does sub-file
synchronization, synchronizing the ferret index could be slow.
And conflicts won't really be mergeable; you'll have to pick one version
or the other.

---

From: [email-masked] (Gabriel Sean Farrell)
Date: Tue, 5 Feb 2008 16:03:42 -0500

> be the primary machine but that doesn't work for a couple of other various

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

---

From: [email-masked] (Gabriel Sean Farrell)
Date: Tue, 5 Feb 2008 16:11:41 -0500

> Sup will probably never work well in this kind of setup.

Agreed.  Thanks for the honest assessment.

---

From: [email-masked] (William Morgan)
Date: Tue, 05 Feb 2008 14:02:37 -0800

> Sup will probably never work well in this kind of setup.

Until we make SupServer!

---

From: [email-masked] (Gabriel Sean Farrell)
Date: Wed, 6 Feb 2008 17:37:33 -0500

> > Sup will probably never work well in this kind of setup.

Something like SupServer could be exciting.  Along with its shortcomings
in the display department, mutt also suffers in a multiple-client-IMAP
setup.  For example, I see no reason why I should keep aliases and list
subscriptions for each client.

---

From: [email-masked] (Marcus Williams)
Date: Thu, 07 Feb 2008 08:45:33 +0000

> > Sup will probably never work well in this kind of setup.

I never know if you're joking when you say stuff like this :) Joking
aside though, if you treat sup as a frontend for a database (which is
basically what it is forgetting the email client side) all you
actually need is to get ferret to run as a server.... and if thats all
you need perhaps we can use the work on the DRb server for the RoR
act_as_ferret plugin and have a remote index that sup can then be a
client of.

This then leads me to a wishlist item - perhaps the contacts stuff
should be moved into a ferret db. That way sup can be a searchable
contacts db as well (and it can be remote so shared across clients).

Any thoughts?

Marcus

---

From: [email-masked] (William Morgan)
Date: Thu, 07 Feb 2008 10:12:43 -0800

> Any thoughts?

Why is it that people are so excited about having an email clients with
this crazy client/server architecture? We don't demand that of any other
console program we use.

If you can run a sup server somewhere, surely you can run sshd there
instead. The only difference would be UI lag on slow connections. Is
that the big win?

---

From: [email-masked] (Gabriel Sean Farrell)
Date: Thu, 7 Feb 2008 15:12:34 -0500

> this crazy client/server architecture? We don't demand that of any other

Let's see, what console programs do I have open right now?  Mutt, irssi,
lynx, tintin++, and btlaunchmanycurses.  We've already discussed Mutt.
irssi is a great example of a console program that acts as a client to a
server.  lynx is an example of the most commonly understood
client/server relationship today.  tintin++ is a mud client, and the
improvements it has over simple telnet clients in the specific domain of
muds could serve as a model for others that rely on ssh/sftp/etc for
other domains.  btlaunchmanycurses is a curses bittorrent client and,
being bittorrent, connects to other clients instead of a server.
Nonetheless, it demonstrates another protocol that I choose a console UI
for.

Even Vim provides the option of editing via sftp and scp, essentially
creating a client connection to files on a server.  It's a pretty
fantastic feature that I recommend you try out if you haven't done so
already.

> instead. The only difference would be UI lag on slow connections. Is

The ability to access these programs over ssh is part of the reason I
use them, but I prefer running them on the local box because UI lag and
dropped connections have frustrated me enough that I'd rather not deal
with them when I don't have to.

---

From: [email-masked] (Marcus Williams)
Date: Thu, 07 Feb 2008 21:09:05 +0000

> instead. The only difference would be UI lag on slow connections. Is

Man, your throw away suggestions should come with "warning, bear trap
ahead" notices :)

For me, the biggest draw of having it as a service is multi-app usage.
I treat sup as a view upon my email but I use my email for a whole lot
of things and sup doesnt (yet) give me views of this data if you see
what I mean. For instance - I might mark emails as todos via the
message hooks so I can email myself todos. I dont need to see who
these are from or the date of these email, just the snippet. Also I
dont really want to go into sup to get these I'd rather have them
available via http. I can do this read only now, but if I want to do
any interactions with this "view" I need to go via sup really. Also I
cant do this when sup is open on my machine as its got the index open
and I'm not sure ferret lets you do multi-user access to the index.

Console access is great when you've got it, but its not so good on a
phone/pda (I am determined to get it running locally on my n800
though!) - so accessing the index through other ways would be useful
here.

Also, sup *is already* a client/server console tool - you're accessing
imap or maildir-over-ssh as a client. The beauty of IMAP (_not_ the
protocol which I have to agree sucks) is the fact I can use any client
I want *locally* and have the same view upon my email anywhere. I dont
have to save an attachment to a disk on my imap server, open winscp to
go to that server pick up the attachment and save locally to view it
on my machine at work or battle with x11 auth and install x11/gnome
packages on my server so I can view it over X11 over ssh.

Dont get me wrong, for my biggest usage sup doesnt need to use the
index over a networked service, I could write most stuff as ruby cgis
or RoR that access the ferret index because most of the time sup wont
be running so wont care. Its just I wouldnt have to worry about it if
it was networked :) and I think it would open up more possibilities of
the use of the index (again, I'm thinking "views" upon my data not
necessarily sup's usage).

Marcus