From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel@gnu.org
Subject: Re: Turning Gnus groups into real objects
Date: Sun, 21 Jul 2019 16:02:15 +0200 [thread overview]
Message-ID: <87y30r5vvc.fsf@mouse.gnus.org> (raw)
In-Reply-To: <877e8c2mhe.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sat, 20 Jul 2019 18:41:01 -0700")
Eric Abrahamsen <eric@ericabrahamsen.net> 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
next prev parent reply other threads:[~2019-07-21 14:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 19:29 Turning Gnus groups into real objects Eric Abrahamsen
2019-07-17 21:33 ` Andy Moreton
2019-07-17 22:04 ` Eric Abrahamsen
2019-07-17 21:59 ` Stefan Monnier
2019-07-17 22:08 ` Eric Abrahamsen
2019-07-18 11:59 ` Lars Ingebrigtsen
2019-07-18 18:01 ` Eric Abrahamsen
2019-07-19 12:56 ` Lars Ingebrigtsen
2019-07-19 18:47 ` Eric Abrahamsen
2019-07-19 22:10 ` Stefan Monnier
2019-07-19 23:56 ` Eric Abrahamsen
2019-07-20 12:52 ` Lars Ingebrigtsen
2019-07-21 1:41 ` Eric Abrahamsen
2019-07-21 12:34 ` Barry Fishman
2019-07-22 17:14 ` Eric Abrahamsen
2019-07-21 13:40 ` Stefan Monnier
2019-07-22 16:38 ` Eric Abrahamsen
2019-07-21 14:02 ` Lars Ingebrigtsen [this message]
2019-07-22 16:26 ` Eric Abrahamsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y30r5vvc.fsf@mouse.gnus.org \
--to=larsi@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).