From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50275 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: Why article numbers? Date: Sat, 22 Feb 2003 16:43:37 -0500 Organization: What did you have in mind? A short, blunt, human pyramid? Sender: owner-ding@hpc.uh.edu Message-ID: References: <841y2jzrgm.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045950252 13004 80.91.224.249 (22 Feb 2003 21:44:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 22 Feb 2003 21:44:12 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18mhRL-0003NY-00 for ; Sat, 22 Feb 2003 22:44:11 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18mhR5-0002bE-00; Sat, 22 Feb 2003 15:43:55 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 22 Feb 2003 15:44:54 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id PAA00258 for ; Sat, 22 Feb 2003 15:44:43 -0600 (CST) Original-Received: (qmail 6655 invoked by alias); 22 Feb 2003 21:43:40 -0000 Original-Received: (qmail 6650 invoked from network); 22 Feb 2003 21:43:40 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (@129.22.96.25) by 66.230.238.6 with SMTP; 22 Feb 2003 21:43:40 -0000 Original-Received: (qmail 23091 invoked by uid 500); 22 Feb 2003 21:43:59 -0000 Original-To: ding@gnus.org In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sat, 22 Feb 2003 21:24:54 +0100") Mail-Copies-To: nobody Mail-Followup-To: ding@gnus.org Original-Lines: 46 User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50275 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50275 I think I should point out that Kai and I seem to be advocating slightly different things. Kai's suggestion, AIUI, is to use Message-ID header fields as article IDs everywhere. My suggestion is to let backends decide how to identify articles, with the only requirement being that identifiers should be eq if they are supposed to identify the same article. (This includes the possibility of symbols whose names are Message-IDs, but does not require that.) Lars Magne Ingebrigtsen wrote: > prj@po.cwru.edu (Paul Jarc) writes: >> Don't ask for a particular number of articles. Ask for "all unread >> articles". > > That's not what the user asks for. The user may ask for "the last > 200 articles, whether read or unread", or "the last 5 read articles". You're changing the question. Originally you said: >>> How many articles should you fetch if the user wants all unread >>> articles? If the user asks for "all unread articles", then Gnus can ask the backend for "all unread articles". If the user asks for "the last 200 articles, whether read or unread", then Gnus can ask the backend for "the last 200 articles, whether read or unread". If the user asks for "the last 5 read articles", then Gnus can ask the backend for "the last 5 read articles". The point is that the work that benefits from knowing that article IDs are integers does not have to be abandoned; it can simply be pushed inside the backend. So for backends that naturally use integers as identifiers, there would just be a restructuring of the existing code, with approximately zero change in performance. Backends that have to do extra work to assign numbers to articles would have the opportunity to try using other types of objects as IDs, but if that strategy turns out to be worse for whatever reason, then they can still go back to using integers. > "A lot of work" is an understatement I won't argue with that. It might even be so much work that it will never happen, unfortunately. But my claim is that it is possible, and if done right, would not cause performance hits. paul