* [sup-talk] Persistence between IMAP clients
@ 2008-02-04 15:12 Gabriel Sean Farrell
2008-02-04 18:46 ` John Bent
2008-02-05 16:42 ` William Morgan
0 siblings, 2 replies; 13+ messages in thread
From: Gabriel Sean Farrell @ 2008-02-04 15:12 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-04 15:12 [sup-talk] Persistence between IMAP clients Gabriel Sean Farrell
@ 2008-02-04 18:46 ` John Bent
2008-02-05 21:03 ` Gabriel Sean Farrell
2008-02-05 16:42 ` William Morgan
1 sibling, 1 reply; 13+ messages in thread
From: John Bent @ 2008-02-04 18:46 UTC (permalink / raw)
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).
John
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-04 15:12 [sup-talk] Persistence between IMAP clients Gabriel Sean Farrell
2008-02-04 18:46 ` John Bent
@ 2008-02-05 16:42 ` William Morgan
2008-02-05 19:12 ` Magnus Therning
` (2 more replies)
1 sibling, 3 replies; 13+ messages in thread
From: William Morgan @ 2008-02-05 16:42 UTC (permalink / raw)
Reformatted excerpts from Gabriel Sean Farrell's message of 2008-02-04:
> 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.
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
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
2 siblings, 1 reply; 13+ messages in thread
From: Magnus Therning @ 2008-02-05 19:12 UTC (permalink / raw)
William Morgan wrote:
> Reformatted excerpts from Gabriel Sean Farrell's message of 2008-02-04:
>> 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.
>
> 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.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-05 19:12 ` Magnus Therning
@ 2008-02-05 19:51 ` William Morgan
0 siblings, 0 replies; 13+ messages in thread
From: William Morgan @ 2008-02-05 19:51 UTC (permalink / raw)
Reformatted excerpts from Magnus Therning's message of 2008-02-05:
> 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.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-04 18:46 ` John Bent
@ 2008-02-05 21:03 ` Gabriel Sean Farrell
0 siblings, 0 replies; 13+ messages in thread
From: Gabriel Sean Farrell @ 2008-02-05 21:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-05 16:42 ` William Morgan
2008-02-05 19:12 ` Magnus Therning
@ 2008-02-05 21:11 ` Gabriel Sean Farrell
2008-02-05 22:02 ` William Morgan
2 siblings, 0 replies; 13+ messages in thread
From: Gabriel Sean Farrell @ 2008-02-05 21:11 UTC (permalink / raw)
On Tue, Feb 05, 2008 at 08:42:03AM -0800, William Morgan wrote:
> Sup will probably never work well in this kind of setup.
Agreed. Thanks for the honest assessment.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-05 16:42 ` William Morgan
2008-02-05 19:12 ` Magnus Therning
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
2 siblings, 2 replies; 13+ messages in thread
From: William Morgan @ 2008-02-05 22:02 UTC (permalink / raw)
Reformatted excerpts from William Morgan's message of 2008-02-05:
> Sup will probably never work well in this kind of setup.
Until we make SupServer!
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-05 22:02 ` William Morgan
@ 2008-02-06 22:37 ` Gabriel Sean Farrell
2008-02-07 8:45 ` Marcus Williams
1 sibling, 0 replies; 13+ messages in thread
From: Gabriel Sean Farrell @ 2008-02-06 22:37 UTC (permalink / raw)
On Tue, Feb 05, 2008 at 02:02:37PM -0800, William Morgan wrote:
> Reformatted excerpts from William Morgan's message of 2008-02-05:
> > Sup will probably never work well in this kind of setup.
>
> Until we make SupServer!
>
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
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
1 sibling, 1 reply; 13+ messages in thread
From: Marcus Williams @ 2008-02-07 8:45 UTC (permalink / raw)
On 5.2.2008, William Morgan wrote:
> Reformatted excerpts from William Morgan's message of 2008-02-05:
> > Sup will probably never work well in this kind of setup.
>
> Until we make SupServer!
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
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
0 siblings, 2 replies; 13+ messages in thread
From: William Morgan @ 2008-02-07 18:12 UTC (permalink / raw)
Reformatted excerpts from Marcus Williams's message of 2008-02-07:
> 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?
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-07 18:12 ` William Morgan
@ 2008-02-07 20:12 ` Gabriel Sean Farrell
2008-02-07 21:09 ` Marcus Williams
1 sibling, 0 replies; 13+ messages in thread
From: Gabriel Sean Farrell @ 2008-02-07 20:12 UTC (permalink / raw)
On Thu, Feb 07, 2008 at 10:12:43AM -0800, William Morgan wrote:
> 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.
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.
> 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?
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] Persistence between IMAP clients
2008-02-07 18:12 ` William Morgan
2008-02-07 20:12 ` Gabriel Sean Farrell
@ 2008-02-07 21:09 ` Marcus Williams
1 sibling, 0 replies; 13+ messages in thread
From: Marcus Williams @ 2008-02-07 21:09 UTC (permalink / raw)
On 7.2.2008, William Morgan wrote:
> 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?
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-02-07 21:09 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-04 15:12 [sup-talk] Persistence between IMAP clients Gabriel Sean Farrell
2008-02-04 18:46 ` John Bent
2008-02-05 21:03 ` Gabriel Sean Farrell
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox