"Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir))

[Rob Browning <rlb@cs.utexas.edu>]

Simon Josefsson <simon@josefsson.org> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
> 
> > What do 'killed, 'dormant, 'save, 'download, and 'unsend mean?  Do
> > they persist between Gnus sessions?
> 
> Unsend is for nndraft:queue only (I think), killed isn't persistant (I
> think), the others are persistant but if the backend can't implement
> them (some IMAP can't store flags) Gnus keep them in .newsrc.eld.  So
> you shouldn't need to worry.

(This note is being precipitated by another one of my talented friends
 dumping gnus because it DTWT one too many times.  He loved gnus, but
 over time, there were some problems that just made it untenable for
 him to keep using it.

 I've got some similar problems (though not quite the same), and I'm
 trying to decide how hard it might be to finally fix gnus to address
 my concerns.  In addition, I'm trying to decide whether or not my
 fixes, if any, would be likely to be accepted upstream.  I don't want
 to throw away the effort if I'm trying to go against the direction
 gnus is headed :>)

I've thought about hacking up a backend that fixes some of my major
gripes with gnus, but I didn't know how hard it would be.  One of my
gripes is that you can't easily just archive a group (by
copying/moving directories), and have gnus DTRT.  This is both because
gnus doesn't store the readness info with the files, and because gnus
keeps its own idea about where your groups are - it doesn't just
present you with whatever groups it finds in the nnml source
directory.

For my purposes, I'd like a slightly simplified mail/news reader that
was suspciciously similar (i.e. nearly identical in most ways) to
gnus, but with the following additions (all mostly related to mail,
and not all probably fixable via the backend).

  (please excuse any schemisms in the pseudo-code below)

  - it should be easy to move your groups around, archiving and
    unarchiving (tarring up, storing on tape, whatever), without
    confusing gnus.  This means storing the mark info with the
    backend.  If I delete an nnml directory from the filesystem, the
    next time I start up gnus, I'd just like to see it gone.  If I
    untar an old one, I'd like to see gnus notice it.

  - it should be *very* hard to have an emacs crash totally hose all
    your state information (readness, group hierarchies, layout,
    etc.).  This means storing the mark info with the backend *and*
    writing it frequently - this may mean *not* writing out a
    monolihic state file, not even one per backend group.

  - it should allow every article to be marked with an arbitrary
    number of "tags".  Some of the tag names (perhaps all prefixed
    with "gnus:", like "gnus:unread") would be reserved for internal
    use, but others would be available for the user.

  - it should be easy to write code that will take actions based on
    the user tags.

  - it should be easy to write code that changes the "system" state of
    an article: (add-system-article-mark article 'gnus:unread)

  - it should have one clear policy with respect to marking articles
    read, and/or deleting them.

  - it should be *easy* to understand this policy, and to override
    it.  I'd like to be able to do things like this and expect them to
    interact well with the rest of the system:

       (setq gnus-expire-check
        (lambda (article)
          (or (normal-system-expire-check article)
              (article-user-mark? article 'garbage)
              (article-user-mark? article 'spam))))

  - it should be easy for the user to map over articles with code that
    makes it obvious what's going on:

      (gnus-group-map-all-articles backend "inbox"
        (lambda (article)
          (if (search-article-for "MONEY")
            (add-article-user-mark article 'spam))))

  - it should handle very large groups efficiently (maybe even with an
    sql backend option).

Perhaps gnus can already do this stuff and I just don't know it, but
if not, anyone have any thoughts about how hard this would be to add?

I've also wondered how hard it might be to turn much of the gnus code
into a mail related emacs library.  Gnus has a tremendous quantity of
excellent mail related code, and it's stuff that's hard to get right.
It would be really nice if this code were avaialbe for re-use so that
if someone's just not quite happy with gnus, they could still use the
library, create something that more closely suits their needs, and
continue to contribute to the development of the common code.

Thoughts?

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930