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