From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85265 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Two issues with the gnus-registry Date: Tue, 11 Nov 2014 10:55:46 +0800 Message-ID: <87y4ria1jh.fsf@ericabrahamsen.net> References: <87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415674278 19646 80.91.229.3 (11 Nov 2014 02:51:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 02:51:18 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33509@lists.math.uh.edu Tue Nov 11 03:51:10 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xo1Xy-0003eT-G6 for ding-account@gmane.org; Tue, 11 Nov 2014 03:51:10 +0100 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 1Xo1Xc-0004QX-ON; Mon, 10 Nov 2014 20:50:48 -0600 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 1Xo1Xb-0004QJ-0d for ding@lists.math.uh.edu; Mon, 10 Nov 2014 20:50:47 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Xo1Xa-0004ls-53 for ding@lists.math.uh.edu; Mon, 10 Nov 2014 20:50:46 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1Xo1XY-0007yy-Ot for ding@gnus.org; Tue, 11 Nov 2014 03:50:44 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xo1XX-0003Oj-JG for ding@gnus.org; Tue, 11 Nov 2014 03:50:43 +0100 Original-Received: from 123.123.17.194 ([123.123.17.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Nov 2014 03:50:43 +0100 Original-Received: from eric by 123.123.17.194 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Nov 2014 03:50:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 62 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 123.123.17.194 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:nPXV9bWxqVPsx6Z3nZC+T35SD2s= X-Spam-Score: -0.3 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85265 Archived-At: Ted Zlatanov writes: > On Sat, 08 Nov 2014 16:39:48 +0800 Eric Abrahamsen wrote: > > EA> So unless I'm really missing something, my proposal is: > > EA> 1. Only provide one limit: max-size. > EA> 2. Allow customization of prune-factor. > > EA> That seems like all the customization you'd need. Cap the size, and > EA> provide a reasonable control of how often the registry gets pruned. > > OK. I am afraid I made the whole thing too complicated and it took > another set of eyes to recognize it. Thanks for that, and the fixes. > > Please go ahead and apply any changes you have in mind. I am sure no one > is tuning soft/hard pruning. Simpler is definitely better. Cool, mostly I'm glad I'm not missing something -- I discovered over several days of staring at it that I'm pretty bad at mental math. > EA> That would require a change in the object signature, which would mean > EA> some extra handling code for "upgrading". But once we're doing that, we > EA> could also take the opportunity to add :prune-function and > EA> :sort-function slots on the base registry object, which would be > EA> nice. We could even change the default store filename from its "eioio" > EA> extension to "eieio". :) > > Yeah, I remember that bug report about the extension of the database > file, if we're upgrading anyway... It's a good chance to batch these > changes. Okay. I guess this will require some (slightly unfortunate) one-off code that will have to live in the codebase for quite some time, but I'll try to make it as unobtrusive as possible, perhaps using advice. Maybe it should even go in a separate file? If there's something else you've been meaning to tweak regarding the database format, let me know and let's get it done! You mentioned wanting to provide alternate data storage options: I doubt I'll be of much help there, but maybe we could leave a stub in place so that future expansions don't require file format changes. It might even make sense to separate the registry object and its :data store. The persistent object, as it behaves right now, might look like: (registry-db "Gnus Registry" :file ".gnus.registry.eieio" :max-size 50000 :data (file ".gnus.registry.dat")) That would probably leave all the flexibility you'd need for future extensions. And... while I'm pulling things out of my rear end, I've also thought it would be nice if the Gnus registry was actually a subclass of the registry class. If all the message tracking stuff was done in methods, it would be very easy for people to make their own special-purpose Gnus registries. Anyway, something to think about for the future. Eric