Re: Probable bug in nnimap

[Simon Josefsson <jas@pdc.kth.se>]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> > On a more philosophical note: it will be nice when(if?) this
> > dependence on a linear, numeric primary key for article identity goes
> > away in gnus... Indeed gnus started life as a nntp-news reader, but I
> > don't even use it for that anymore... email (in various flavors) and
> > the web-group stuff is far more useful day-to-day...
> 
> Yes, it would be useful to think about an ADT `article number' (though
> number is the wrong word, didn't want to use id lest there be
> confusion with message id).  What operations does one need on that
> ADT?  Gnus could then be changed to use that ADT and then the ADT
> could evolve to accomodate new backends.

I remember a silly idea I had some time ago, we could use wmperry's
URL package as an interface to backends, and simply have Gnus be a
yet-another-generic-url-viewer.

(w3+Gnus?  That would be the Grand Unified Program, wouldn't it?  Hm.
GUP.  Sounds nice.)

Anyway, so, in the group buffer "groups" are simply URLs, on the form
"imap://myserver/INBOX.foo", "nnml://mailbox/?nnml-directory=~/foobar"
or whatever. The corresponding url-handler for nnml, imap etc must be
able to somehow return short, quick data for the group (such as number
of read articles). (Is there something to utilize HTTP HEAD in the
url-package?  The nnml url handler might return "X-gnus-read: 42" or
something then.).

The summary buffer also render URLs, now on the form of
"nnml://mailbox/42". Article info (subject, from, to etc) should be
returned in a HTTP HEAD-similar manner too. When fetching the entire
URLs, all data should be MIME tagged (nnml backends only support
message/rfc822 content, but other backends might support other stuff).

While I'm at it, we'd might as well make it work in JEmacs and have
multithreading and cool GUI widgets too.

I'm being quite silly. I'll shut up now. :-)