From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14986 invoked from network); 18 Jan 2021 09:39:45 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 18 Jan 2021 09:39:45 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l1R0g-00Gniv-Ux for ml@inbox.vuxu.org; Mon, 18 Jan 2021 03:39:42 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1l1R0g-006qCr-F6 for ml@inbox.vuxu.org; Mon, 18 Jan 2021 03:39:42 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l1R0e-006qCh-5l for ding@lists.math.uh.edu; Mon, 18 Jan 2021 03:39:40 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l1R0c-005Fcg-40 for ding@lists.math.uh.edu; Mon, 18 Jan 2021 03:39:39 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References :Message-ID:Date:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3QpBsdheE0mdIg3D6rhYkfQElvfTATvuUXo5a55HNoY=; b=DpKklxSPxpIsh5n3CkBKDdBTlc YyBfHWZfKTdlk/YaUM80Ni/A9eU+WoUJDKT+emE6EmGR2YGN66DjQrZ3QI+PPdu8aKtNVEIuzuARv gvLWxqi9c932Zx9uc1VPL+xF5Ix31VfYB6FHnsoawSqY+I4Fats0e5j5qaSMqZAMTDw0=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1R0N-0000la-N5 for ding@gnus.org; Mon, 18 Jan 2021 10:39:33 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1l1R0M-0006Oo-Ak for ding@gnus.org; Mon, 18 Jan 2021 10:39:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Subject: Re: Experimental new Maildir backend Date: Mon, 18 Jan 2021 10:39:15 +0100 Message-ID: <86ft2yh9do.fsf@csic.es> References: <86h7ngen1y.fsf@csic.es> <875z3w9nhm.fsf@ericabrahamsen.net> <868s8sdjii.fsf@csic.es> <87ft2z8d0a.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (windows-nt) Cancel-Lock: sha1:fItbRZ/sTZ3+ApUV8OoI698fFG8= List-ID: Precedence: bulk Eric Abrahamsen writes: > Juan José García-Ripoll writes: >> Hi Eric, nice to see you also are interested in this format. I also >> started tweaking nnmaildir. I got to a point where I fixed the >> separator, introducing a configuration parameter that starts with ":" >> but can be configured to other values. Unfortunately the result was >> extremely slow. > > You mean making that character configurable actually introduced a > slowdown? It seems odd that it would be that much of a factor. No, sorry for the confusion: the change of the separator is trivial, and does not affect overall performance, but the actual backend is simply too slow for platforms where file creation, time stamp checking and linking are not cheap operations. >> I started using inheritance, but it did not work. The parent backend did >> not get its variables properly assigned > > To me this is usually a sign that there are code paths that don't hit > `nnoo-change-server'. I see you've got that in `nnmaild-open-server', > which gets called in `nnmaild-possibly-change-directory', but I would > take a look at the various code entry points and see if any of them > sneak past that. Also, you're calling `nnmaild-server-opened', but that > function doesn't seem to be defined? Again, sorry for my confusing explanation. What follows is an explanation of how I attempted it, not how it is done in my repository. In the version from GitHub, everything works and no inheritance is needed. To be fair no inheritance is possible because I ended up doing things differently from nnml, with a different caching protocol, and a totally different way of handling marks. As for my first attempts, I started using inheritance as per the nndir example. In that case, I wanted to reuse nnml's file scanning and NOV caching, which is why I created manually the nnmaild-request-* functions. These attempts would perform some tasks before calling the the functions of the parent backend with the same name. The problem there is that while all variables are properly defined in the child (including those variables that in defvoo specify alternative names for the child framework, i.e. nnmaild-directory translated to nnml-directory), the variables were arbitrarily restored to default values when the parent functions were alled. I am sorry, but I do not keep that code around, although it would not be difficult to try again. > This is too bad, and something else that I would (theoretically, > eventually) like to work on. If a new backend looks highly similar to an > existing backend, it should be able to share a lot of the code. There was no real code reuse. nnmaildir's functions are impossible to reuse; nnml's relies heavily on numbered files and uses a different way of caching NOV's > What do you mean exactly, "tell Gnus the attributes of a message"? It took me quite a lot of debugging to develop the functions that modify the info structure replacing the marks with those that are given by the Maildir backend. It was not clear from the documentation where that is supposed to happen. nnml has no implementation for marks, delegating everything on the Gnus dribble files. nnimap has an undocumented implementation that uses the fact that it has a request and a finish- processing stages. > If you have concrete suggestions as to how Gnus could do a better job > of allowing inheritance, I'd love to hear it. To be fair, I am quite lost regarding how inheritance is handled and how the whole infrastructure works. - I find it confusing the way defvoo works and the fact that everything is based on variables instead of objects, methods and slots. - In particular, coming from an OO background (both in Common Lisp and C++), I do not understand when and how those variables are rewritten. In OO paradigms, one fixes the slots of the parent classes during the construction phase; here it seems there is some magic rewrite happening at hidden places. - This made it confusing to me how I can write my own defvoo method and, from within that method call equivalent methods from other backends. That does not seem to be supported. - On a more architectural note, it is also strange that methods are expected to work with global state, instead of getting properly formed records. This makes the handling of group, server and info objects very confusing -- when do they have a value, vs. when can they be just nil, still puzzles me. - I also find that, for proper inheritance, some of the backends should have less assumptions about the underlying system (e.g. nnml should not assume numbering of files), allowing the rewrite of specific methods (e.g. retrieval and writing of marks), which in the current framework seems very difficult, as there are no real virtual functions. Hope this helps clarify how confused I am about inheritance. This said, I think I now understand how to write the backend _without_ inheritance. Juanjo -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es