From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Turning Gnus groups into real objects Date: Sun, 21 Jul 2019 16:02:15 +0200 Message-ID: <87y30r5vvc.fsf@mouse.gnus.org> References: <87k1cg5ujl.fsf@ericabrahamsen.net> <87wogf8sei.fsf@mouse.gnus.org> <87zhlb2per.fsf@ericabrahamsen.net> <877e8e89os.fsf@mouse.gnus.org> <87ftn17tey.fsf@ericabrahamsen.net> <87o91o7try.fsf@mouse.gnus.org> <877e8c2mhe.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="21895"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 16:02:41 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hpCQ9-0005Ud-NG for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2019 16:02:37 +0200 Original-Received: from localhost ([::1]:56164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpCQ8-0006kC-C0 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2019 10:02:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54520) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpCQ0-0006ju-VP for emacs-devel@gnu.org; Sun, 21 Jul 2019 10:02:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpCPz-0003gU-Lk for emacs-devel@gnu.org; Sun, 21 Jul 2019 10:02:28 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:52838) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hpCPu-0003aM-Bt for emacs-devel@gnu.org; Sun, 21 Jul 2019 10:02:24 -0400 Original-Received: from [80.169.244.84] (helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hpCPn-0004Qc-Sf; Sun, 21 Jul 2019 16:02:18 +0200 In-Reply-To: <877e8c2mhe.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sat, 20 Jul 2019 18:41:01 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238768 Archived-At: Eric Abrahamsen 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