From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80124 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.gnus.general Subject: Re: nnir, gnus-goto-article and such Date: Thu, 29 Sep 2011 10:40:50 -0400 Message-ID: References: <87pqinvvg4.fsf@lifelogs.com> <87aa9pu1tx.fsf@lifelogs.com> <878vp8nq6y.fsf@lifelogs.com> <87sjnfn486.fsf@lifelogs.com> <87oby3jvna.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1317308046 16728 80.91.229.12 (29 Sep 2011 14:54:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Sep 2011 14:54:06 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M28418@lists.math.uh.edu Thu Sep 29 16:54:01 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R9Hzs-0000CS-5i for ding-account@gmane.org; Thu, 29 Sep 2011 16:54:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1R9Hzq-0007vb-3H; Thu, 29 Sep 2011 09:53:58 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1R9Hzo-0007vO-SE for ding@lists.math.uh.edu; Thu, 29 Sep 2011 09:53:56 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R9Hzn-0007Sa-A7 for ding@lists.math.uh.edu; Thu, 29 Sep 2011 09:53:56 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1R9Hzl-0007u2-R5 for ding@gnus.org; Thu, 29 Sep 2011 16:53:53 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R9Hzk-00009h-Hz for ding@gnus.org; Thu, 29 Sep 2011 16:53:52 +0200 Original-Received: from h-67-100-201-170.cmbrmaor.static.covad.net ([67.100.201.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Sep 2011 16:53:52 +0200 Original-Received: from dave by h-67-100-201-170.cmbrmaor.static.covad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Sep 2011 16:53:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: h-67-100-201-170.cmbrmaor.static.covad.net User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin) Cancel-Lock: sha1:nEfesVMe/v1jpNCiB2qa+Pq+Ox4= X-Spam-Score: -5.4 (-----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80124 Archived-At: on Thu Sep 29 2011, Ted Zlatanov wrote: > On Thu, 29 Sep 2011 09:40:54 -0400 Dave Abrahams wrote: > > DA> [Aside: it seems like this territory is full of components that > DA> could in principle be nicely generalized, but whose implementation > DA> has only been made to work for one specific usage scenario] >>> >>> I can't tell, I was not involved with writing these components. > > DA> IIUC from reading elsewhere you rewrote the registry. > > I wrote *registry.el but I was talking about nnir.el, nnregistry.el, and > other search functionality. The registry is not a search engine so I > thought you didn't mean it. I'm not sure how it could be generalized > and in what direction--tell me what you think. Well, it's in the territory, but it's not one of those components. I don't have any complaints about the registry itself. I was referring more to things like gnus-warp-to-article, which only functions on a single kind of group, or general usage of the registry, which only happens in a very few circumstances even though the kind of queries the registry can answer are all over the place. >>> At least for the registry I know it's optional so we can't depend on >>> it. > > DA> I'm not sure what "optional" means in this context. Is Gnus going to > DA> ship without the registry code? > > Users should be able to use every aspect of Gnus without calling > `gnus-registru-initialize'. The memory usage of the gnus-registry, if > we enabled it by default, would be unpleasant for many of our users on > older or less capable machines. Thus any general Gnus functionality > should not depend on the gnus-registry's availability. Well, here's an example of a missing generalization then. The registry provides a general interface for looking up (information about) articles based on their message IDs. However, there's only one of them, and it's persistent. nnir would only need a small, special-purpose registry for each of its groups. Or, maybe better, one registry could be refcounted and just discarded when you leave the last nnir group if you haven't initialized the registry in the meantime. It wouldn't grow if nobody was putting things in it. > Furthermore the gnus-registry should be treated as a lossy cache. If > you find something useful, great. But don't rely on it. That attitude > lets us expire it more aggressively. There are "precious" properties > you can set, so for instance the registry marks are not lost, but from > our side we can't expect that. Sorry, don't know what you mean by "our side." You can't make things precious programmatically? -- Dave Abrahams BoostPro Computing http://www.boostpro.com