From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32880 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: "Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir)) Date: 17 Oct 2000 22:51:36 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87aec3o3u6.fsf_-_@raven.localnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035169088 22257 80.91.224.250 (21 Oct 2002 02:58:08 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:08 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 75E47D051E for ; Tue, 17 Oct 2000 16:52:40 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id PAB27997; Tue, 17 Oct 2000 15:52:14 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 17 Oct 2000 15:51:38 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id PAA25704 for ; Tue, 17 Oct 2000 15:51:27 -0500 (CDT) Original-Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by mailhost.sclp.com (Postfix) with ESMTP id B7097D051E for ; Tue, 17 Oct 2000 16:51:45 -0400 (EDT) Original-Received: from barbar.josefsson.org (localhost.localdomain [127.0.0.1]) (authenticated) by dolk.extundo.com (8.11.1/8.11.1) with ESMTP id e9HKpid22687; Tue, 17 Oct 2000 22:51:44 +0200 Original-To: Rob Browning In-Reply-To: <87aec3o3u6.fsf_-_@raven.localnet> Mail-Copies-To: nobody Original-Lines: 118 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:32880 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32880 Rob Browning writes: > I've got some similar problems (though not quite the same), and I'm > trying to decide how hard it might be to finally fix gnus to address > my concerns. In addition, I'm trying to decide whether or not my > fixes, if any, would be likely to be accepted upstream. I don't want > to throw away the effort if I'm trying to go against the direction > gnus is headed :>) Where are we headed? > I've thought about hacking up a backend that fixes some of my major > gripes with gnus, but I didn't know how hard it would be. One of my > gripes is that you can't easily just archive a group (by > copying/moving directories), and have gnus DTRT. This is both because > gnus doesn't store the readness info with the files, and because gnus > keeps its own idea about where your groups are - it doesn't just > present you with whatever groups it finds in the nnml source > directory. I think you'll find, as at least I have, that it's hard to solve these problems by hacking up a backend. Backends simply doesn't have any influence on what Gnus does. > - it should be easy to move your groups around, archiving and > unarchiving (tarring up, storing on tape, whatever), without > confusing gnus. This means storing the mark info with the > backend. If I delete an nnml directory from the filesystem, the > next time I start up gnus, I'd just like to see it gone. If I > untar an old one, I'd like to see gnus notice it. Yes. In a similar note, nnml groups should by default live in ~/Mail/nnml/ to make this more doable. > - it should be *very* hard to have an emacs crash totally hose all > your state information (readness, group hierarchies, layout, > etc.). This means storing the mark info with the backend *and* > writing it frequently - this may mean *not* writing out a > monolihic state file, not even one per backend group. Absolutely. It would be easy to copy nnml into nnmlng and implement nnmlng-request-set-mark. This would make flags live in the backend. But we'd still have legacy stuff in .newsrc.eld that isn't really used. In OGnus I hope we can make the entire .newsrc.eld file optional. > - it should allow every article to be marked with an arbitrary > number of "tags". Some of the tag names (perhaps all prefixed > with "gnus:", like "gnus:unread") would be reserved for internal > use, but others would be available for the user. This isn't very difficult, I think. > - it should be easy to write code that will take actions based on > the user tags. What do you mean? > - it should be easy to write code that changes the "system" state of > an article: (add-system-article-mark article 'gnus:unread) This is tricky. What datatype is article? Currently articles are atomic entities, numbered with elisp integers. Some time ago, I had a slightly crazy idea to use URLs in Gnus. I still think it's a good idea, but it would require some work. This way we'd have an extensible framework in place, and adding support for partial message fetching and similar things wouldn't be difficult. With Bill Perry's URL package, we'd might even get asynchronous support and other niceties. > - it should have one clear policy with respect to marking articles > read, and/or deleting them. > > - it should be *easy* to understand this policy, and to override > it. I'd like to be able to do things like this and expect them to > interact well with the rest of the system: > > (setq gnus-expire-check > (lambda (article) > (or (normal-system-expire-check article) > (article-user-mark? article 'garbage) > (article-user-mark? article 'spam)))) This isn't very complicated today, but it's hidden from the user in a way that make it seem complex. IMHO. > - it should be easy for the user to map over articles with code that > makes it obvious what's going on: > > (gnus-group-map-all-articles backend "inbox" > (lambda (article) > (if (search-article-for "MONEY") > (add-article-user-mark article 'spam)))) > - it should handle very large groups efficiently (maybe even with an > sql backend option). SQL seem to pop up once in a while as a solution to these problems, but the only performance issues I've seen are inside Gnus and they wouldn't be solved by changing the backend. I seriously doubt that a SQL backend would be faster than a specialized database such as nnml or nnfolder (or IMAP for that matter). > I've also wondered how hard it might be to turn much of the gnus code > into a mail related emacs library. Gnus has a tremendous quantity of > excellent mail related code, and it's stuff that's hard to get right. > It would be really nice if this code were avaialbe for re-use so that > if someone's just not quite happy with gnus, they could still use the > library, create something that more closely suits their needs, and > continue to contribute to the development of the common code. I've thought of this many times, but it's difficult to isolate "common code" and cast an API to it in stone. Writing mail (message buffer) and reading mail (article buffer) are pretty isolated, and that's a good thing. Server structures, article flag structures and group structures are touched everywhere by lots of code, and this is were much of the complexity stem from, I think.