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=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23022 invoked from network); 17 Jan 2021 21:34:03 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 17 Jan 2021 21:34:03 -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 1l1FgM-00GPnG-1x for ml@inbox.vuxu.org; Sun, 17 Jan 2021 15:33:58 -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 1l1FgL-006jtp-Fl for ml@inbox.vuxu.org; Sun, 17 Jan 2021 15:33:57 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l1FgJ-006jth-9P for ding@lists.math.uh.edu; Sun, 17 Jan 2021 15:33:55 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l1FgH-00GPmz-2Q for ding@lists.math.uh.edu; Sun, 17 Jan 2021 15:33:54 -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=oK7d2CAweHn7RQrkDtyAxqlOvrr89LC3U0yAAWRQXkI=; b=nB2ECh8cb+Op706Utcgvc7s+um LcIEXt8s5YNJ6ISmTKIYWdGkIqaFYlMQfAXggTeta8DJ6Uj7pVlLTlNTt0eJoL63/syxgwpxAZh7f r3yHNtQHEmdWWB46TRhgFr+MWHeS7tYRrAXx5nRylnk1ffGMBbE5+bJNmsaxQWF2SPs0=; 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 1l1Fg3-0001vF-CL for ding@gnus.org; Sun, 17 Jan 2021 22:33:48 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1l1Fg1-0004vQ-Sq for ding@gnus.org; Sun, 17 Jan 2021 22:33:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: Experimental new Maildir backend Date: Sun, 17 Jan 2021 13:33:25 -0800 Message-ID: <87ft2z8d0a.fsf@ericabrahamsen.net> References: <86h7ngen1y.fsf@csic.es> <875z3w9nhm.fsf@ericabrahamsen.net> <868s8sdjii.fsf@csic.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:yL3LEO36EWbRgPfMAMOooBE2fRM= List-ID: Precedence: bulk Juan José García-Ripoll writes: > Eric Abrahamsen writes: >> Very cool! It's great to see work on more backends. I'm also in the >> process of putting together fixes for nnmaildir, so there might be a >> little bit of redundancy in our work, but it looks like your approach is >> a more drastic rethinking -- my changes are mostly incremental tweaks. > > 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. > I gather Maildir creates one NOV file for every message, it also creates > a folder for each flag and creates links (which I am not even sure > whether it does correctly on Windows, where links are not always > possible), for every article that has a mark. That made a folder with > ~900 emails take minutes to load at all. I know that this is a Windows > limitations but I think it points out how wasteful it is. In contrast, > the archives I have based on nnml are very snappy. Yeah, the whole setup is a little baroque. But I think this is the dividing line between what I'm likely to do with nnmaildir, and where it makes sense to write a new backend. I don't think I would change nnmaildir's architecture, just try to fix some basic inefficiencies. If users want a more drastic change, it makes more sense to just have a new backend. >> I saw on the github page that this is based off nnml code, and there are >> several functions (moving messages, creating groups) that haven't been >> implemented yet. I'm curious if you were able to use any of Gnus' >> backend inheritance features -- are you having to write everything from >> scratch? I haven't read the code yet... > > 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? > and there were lots of confusing group names: i.e. Archives.2011 would > have to be renamed Archives.2011.cur so that nnml tries to first find > that directory and then attempts Archives.2011/cur. However, at some > point I also was not satisfied with nnml's approach, which only stores > the NOV files and enforces that all file names must be a number (the > article number) and I gave up. The result is not that bad, ~500 lines. > The biggest hurdle was figuring out which backend functions need to be > created for the backend to tell Gnus the attributes of a message. That > is not at all clear in the manual and nnmaildir, nnimap and others > seem to follow different not well documented paths. 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. What do you mean exactly, "tell Gnus the attributes of a message"? If you have concrete suggestions as to how Gnus could do a better job of allowing inheritance, I'd love to hear it. Eric