Gnus development mailing list
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@work.lexort.com>
To: John Owens <john_owens@yahoo.com>
Cc: ding@gnus.org
Subject: Re: Agent & disconnected IMAP: move messages between folders?
Date: Sat, 03 Jan 2009 11:36:15 -0500	[thread overview]
Message-ID: <smusko0l534.fsf@linuxpal.mit.edu> (raw)
In-Reply-To: <loom.20090103T014508-632@post.gmane.org> (John Owens's message of "Sat, 3 Jan 2009 01:48:03 +0000 (UTC)")


John Owens <john_owens@yahoo.com> writes:

> John Owens <john_owens <at> yahoo.com> writes:
>
>> (I read email in the following way: most stuff comes into my
>> inbox, I read it, I answer it, I file it into a folder. Thus
>> such a capability is useful to me. I am totally willing to hear
>> about a more Gnus-y way to handle this, but I don't think 
>> "auto-filter every message that comes in into its destination"
>> is ideal for me, since I get lots of mail that would be hard
>> to categorize like that.)
>
> So I'd like to hear about a more Gnus-y way to do this. The good
> thing about Gnus (compared to Wanderlust) is it has a much larger
> user community and a much more active developer community. 
> Disconnected IMAP would seem to be something that would be useful
> for lots of people, so I'd suspect that the reason it's not 
> currently supported (at least this feature) is less "this is a
> feature we haven't got to yet" and more "well, people just use Gnus
> in this different way that obviates the need for such a feature".
> Thoughts? What is the common usage pattern for disconnected IMAP?

I've somewhat struggled with the same issue.

The gnus-y way is to have mail arrive and leave it there, treating it as
read news, and never deleting it.  I don't read mail like that either.

What I do is filter most of my mail to separate IMAP folders (outside of
gnus, at delivery time).  Examples are mailing lists, commit messsages
per project, plus anything else that I can identify and don't need to
know about in a timely manner.  Spam scoring N spamassassin points for N
>=1 goes to spam.N.  Many of these folders I read only with gnus.  On
some I use total-expire, and most of the rest auto-expire.

Then my INBOX gets unfiltered mail, and some of that I file manually
(with B m).  On other messages I type 'd' which is bound to:

(setq gdt-trash-newsgroup "nnimap+[machine-name]:Trash")
(defun gdt-gnus-move-to-trash ()
  (interactive)
  (gnus-summary-move-article nil gdt-trash-newsgroup))

via
      (add-hook
       'gnus-summary-mode-hook
       (lambda ()
	 (local-set-key "d" 'gdt-gnus-move-to-trash)))

so I generally keep my INBOX small.  This is not gnus-y, but how I want
to read mail, and how I can use other IMAP clients against the same
mailbox - a lot of the point of sorting is to make looking at INBOX on
my phone reasonable.

I don't think there is philosophical opposition to disconnected IMAP -
it's just hard.  Right now the agent seems to be a read-only cache of
the server.  With disconnected IMAP you keep log of operations to play
back later.  I don't know whether implementations typically modify the
cache or play back the log locally when reading the cache, but I suspect
the cache reflects the state with the log operations applied.  All of
this seems doable, and seems like a natural extension to the agent.  You
might want to look at the Coda filesystem for inspiration of how to deal
with things, but Thunderbird might be more useful.  It seems there
should be an open-source disconnected-mode IMAP library.  I wonder if
it's just easier to use an offline IMAP proxy, and if those really
support disconnected mode.

Before getting to offline IMAP, there are some cache consistency bugs to
fix.  When I have the agent enabled, I find ghost articles.  I suspect
that these are from moving the article from a group (message from a
folder :-) with another client.  So there needs to be some sort of
"resynchronize" operation where messages in a folder are listed by UID
or something and then removed from the agent cache if gone on the
server.  Plus any changes made to the server need to be made in the
cache.  Then a change in architecture so that changes are made to the
cache, which makes them locally and then puts them in the playback log,
doing them immediately if possible.

Full disconnected operation might be really hard, but just having the "B
m" operation be supported would be a huge win, since most of what I want
to do disconnected is clean up my INBOX: file messages away and delete
them (which for me is refile to Trash, with Trash having total-expire).



  reply	other threads:[~2009-01-03 16:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-02  3:02 John Owens
2009-01-02 23:42 ` Steinar Bang
2009-01-02 23:54   ` John Owens
2009-01-03  1:14     ` Steinar Bang
2009-01-03  1:48 ` John Owens
2009-01-03 16:36   ` Greg Troxel [this message]
2009-01-03 20:24     ` John Sullivan
2009-01-04 22:33       ` Xavier Maillard
2009-01-04  1:26     ` Steven E. Harris

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=smusko0l534.fsf@linuxpal.mit.edu \
    --to=gdt@work.lexort.com \
    --cc=ding@gnus.org \
    --cc=john_owens@yahoo.com \
    /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;
as well as URLs for NNTP newsgroup(s).