[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Turning Gnus groups into real objects
From: |
Eric Abrahamsen |
Subject: |
Re: Turning Gnus groups into real objects |
Date: |
Mon, 22 Jul 2019 09:26:05 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Lars Ingebrigtsen <address@hidden> writes:
> 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.
Sorry, that was worded wrong.
> 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.
Yes! That was definitely something I had in mind. We shouldn't have to
take server output and munge it into some other server output and then
parse it.
>> (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...
Actually, done right, it should result in *less* code duplication. Code
common to all servers goes in base methods that specialize on
`gnus-server' -- the same code runs for all servers. Code specific to a
class of backends or a single backend goes in a method that augments or
is composed with that base method somehow.
Anyhow, this is moot if we're not changing the interface. At least,
mostly moot...
>> 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.)
Right, that's what I meant by adjusting check-backend-function and
gnus-get-function. Or maybe Stefan's right that there's a way to do it
all with generic functions.
Anyway, it sounds like this might be feasible. I understand we're
keeping support for out-of-tree backends and not changing the backend
interface. It will take me a little while to get to this, but I'll be
back when I've got some proof-of-concept code to look at.
Thanks,
Eric
- Re: Turning Gnus groups into real objects, (continued)
- Re: Turning Gnus groups into real objects, Lars Ingebrigtsen, 2019/07/20
- Re: Turning Gnus groups into real objects, Eric Abrahamsen, 2019/07/20
- Re: Turning Gnus groups into real objects, Barry Fishman, 2019/07/21
- Re: Turning Gnus groups into real objects, Eric Abrahamsen, 2019/07/22
- Re: Turning Gnus groups into real objects, Stefan Monnier, 2019/07/21
- Re: Turning Gnus groups into real objects, Eric Abrahamsen, 2019/07/22
- Re: Turning Gnus groups into real objects, Lars Ingebrigtsen, 2019/07/21
- Re: Turning Gnus groups into real objects,
Eric Abrahamsen <=