From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Turning Gnus groups into real objects Date: Sat, 20 Jul 2019 18:41:01 -0700 Message-ID: <877e8c2mhe.fsf@ericabrahamsen.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="125452"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 03:41:26 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 1hp0qr-000WUt-Ey for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2019 03:41:25 +0200 Original-Received: from localhost ([::1]:54178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp0qq-0006lo-1b for ged-emacs-devel@m.gmane.org; Sat, 20 Jul 2019 21:41:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56783) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp0qi-0006li-H8 for emacs-devel@gnu.org; Sat, 20 Jul 2019 21:41:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hp0qh-0006mi-3L for emacs-devel@gnu.org; Sat, 20 Jul 2019 21:41:16 -0400 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:49266 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hp0qg-0006kT-Mc for emacs-devel@gnu.org; Sat, 20 Jul 2019 21:41:14 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hp0qc-000WIg-R6 for emacs-devel@gnu.org; Sun, 21 Jul 2019 03:41:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:gOm5/rI8OCRNfM6EOnevU1uR8Pc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:238756 Archived-At: Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > [...] > Oh, I see -- want the objects to be in Gnus, not just in the backends? > Yes, then I can see how that'd be more complicated to have the two > interfaces. > > But I don't there's that much value in carrying around the backend > objects inside Gnus. I think the current list-based server objects > could still live on the Gnus side. And I think moving away from those > would lead to, basically, breaking half the Gnus users'.gnus.el files. Okay, maybe this whole thing would end up being too intrusive, then. The point would be to change calling conventions of the server functions, to increase code re-use and composability. I suppose it might be possible to do a bare minimum of replacing nnoo with structs, but then we wouldn't be able to replace deffoo with generics. And I don't see how we could use structs inside the backend file, but lists in the rest of the code. >> I'd aim at a few general principles: >> >> 1. Move more code into the methods, in particular the base methods. > > I'm not sure what you mean here... See below >> 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. >> 3. Let all servers keep track of a list of "their" groups. > > Keep track in what way? > >> 4. Wherever possible, pass servers as arguments instead of guessing them >> from the environment. > > Sure. > >> 5. Keep a "real" list of servers, equivalent to `(cons gnus-select-method >> (append gnus-secondary-select-methods gnus-server-alist))', so we >> don't have to keep looking for them. > > I'm not sure what you refer to -- there's a bunch of code that allows > you to refer to servers based on the name as well as the actual backend > definition (that has grown for historical reasons)... Okay, one theoretical example that combines all of the above (and will probably illustrate why this whole project is a non-starter): Right now, every time you hit "g" in the Group buffer, Gnus cycles over all groups, collects those eligible for refresh, rebuilds the relevant list of servers for those groups, and then asks each server to update its particular subset of groups. What I think could be much cleaner (and I'm not saying this is necessarily a great idea, it's just illustrative) is that `gnus-get-unread-articles' would look like: (defun gnus-get-unread-articles (level) (dolist (server (gnus-all-servers)) (gnus-server-update level))) Where `gnus-all-servers' just returns a list of all the server objects. `gnus-server-update' would be a generic function looking like: (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. Again, this particular case is just for illustration of the principle. 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. I can't think of any other way of preserving compatibility. Probably this just isn't feasible without breaking support. Eric