Re: Turning Gnus groups into real objects

[Lars Ingebrigtsen]

Eric Abrahamsen <address@hidden> writes:

>>> 2. Where possible, give servers their own process buffer (for if we ever
>>> want to make Gnus threaded).
>>
>> Don't they have that already?
>
> Near as I can tell, all the backends dump their remote responses into
> `nntp-server-buffer'. That works fine because they each dump and read in
> turn, and erase the buffer when they start. With threading, the
> responses get dumped in more or less random order, so they end up
> reading each other's responses. I ran into this when I was working on
> gnus-search.el, and got excited about searching multiple IMAP servers
> concurrently, using threads.

Oh, that server buffer.  Yeah, most backends have their own per-server
buffer for communicating with the, er, server, which is then parsed and
then dumped into nntp-server-buffer in the format Gnus expects.

I'd have expected a new backend interface not to use
nntp-server-buffer -- or any buffer -- for communication with Gnus, but
just return articles as a list of objects.  It'd be more efficient.

> (cl-defgeneric gnus-server-update ((server gnus-server)
>                                  level)
>   (let ((groups (seq-filter (lambda (g)
>                             (>= level (gnus-info-level g)))
>                           (gnus-server-groups server))))
>     (when groups
>       update groups...)))
>
> This is what I mean by "move code into base methods" (and
> `gnus-server-groups' is the "keeping track of their groups" part). This
> base method applies to all servers, but different server classes would
> have the opportunity to augment it using :before :after and :around
> methods, or override it completely.

I think that this sounds like code duplication, doesn't it?  And while
IMAP does have an in-backend sense of readedness etc, most of the other
backends don't...

> Anyway, I'm guessing all this would simply be too intrusive. So if we
> wanted to preserve compatibility with backends defined out-of-tree, we
> could a) redefine nnoo-declare/defvoo/deffoo to create ad-hoc structs
> (probably not), or b) adjust gnus-check-backend-function and
> gnus-get-function to check if the server is a list or a struct and
> dispatch to different kinds of functions. But doing it this way would
> mean having to keep nnoo.el, getting none of the benefits of generic
> functions, and adding complexity and confusion.

It would mean keeping nnoo.el, but it'd be deprecated and would
eventually go away.

I don't really see much of a complication here.  You call functions like
`gnus-open-server' (that takes a method), and it'd look at whether the
backend is new-style or old-style and call the backends according to the
new or old conventions.  (And the new-style is, of course, with the
backend state in a struct instead of spread out over a bunch of
variables.)

There's a limited number of interface functions...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no