From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/71791 Path: news.gmane.org!not-for-mail From: Russ Allbery Newsgroups: gmane.emacs.gnus.general Subject: Re: nndebbugs Date: Sat, 25 Sep 2010 17:33:03 -0700 Organization: The Eyrie Message-ID: <8762xt9we8.fsf@windlord.stanford.edu> References: <87r5ghwpnr.fsf@keller.adm.naquadah.org> <87lj6pwo9n.fsf@keller.adm.naquadah.org> <87zkv5y2g4.fsf@turtle.gmx.de> <878w2p7azn.fsf@mid.gehheimdienst.de> <87r5ghbfl4.fsf@windlord.stanford.edu> <87k4m99z0x.fsf@windlord.stanford.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1285461247 11953 80.91.229.12 (26 Sep 2010 00:34:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 26 Sep 2010 00:34:07 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20164@lists.math.uh.edu Sun Sep 26 02:34:05 2010 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 1OzfBs-0005iQ-Q3 for ding-account@gmane.org; Sun, 26 Sep 2010 02:34:05 +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 1OzfBh-00025U-7R; Sat, 25 Sep 2010 19:33:53 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OzfBe-00025A-Rl for ding@lists.math.uh.edu; Sat, 25 Sep 2010 19:33:50 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1OzfBQ-0004Fe-RK for ding@lists.math.uh.edu; Sat, 25 Sep 2010 19:33:50 -0500 Original-Received: from smtp3.stanford.edu ([171.67.219.83] helo=smtp.stanford.edu) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1OzfBP-0004Kv-00 for ; Sun, 26 Sep 2010 02:33:35 +0200 Original-Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B1F3A1A0846 for ; Sat, 25 Sep 2010 17:33:04 -0700 (PDT) Original-Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 6D7B01A085E for ; Sat, 25 Sep 2010 17:33:03 -0700 (PDT) Original-Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3A7B62F48E; Sat, 25 Sep 2010 17:33:03 -0700 (PDT) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 26 Sep 2010 02:17:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Spam-Score: -4.9 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:71791 Archived-At: Lars Magne Ingebrigtsen writes: > Russ Allbery writes: >> Hm, I wonder if there's any way to generate an "article" for each bug, >> which if you open it is treated like a digest of the bug discussion. >> Otherwise, I think the threading between bugs and inside bugs is going >> to make matters rather confusing. > If the messages have References and stuff, it should work as a normal > mail group. If not, it'll still gather threads based on Subject... so > it shouldn't be more confusing than a mailing list from 1992. :-) Yeah, but what you get is a group that contains a discussion of every bug, which means that you've lost the structure that associated particular threads with particular bugs. I don't know that it's a big deal, although I know I wouldn't want to read, say, the bugs on debian-policy that way, since each bug often contains multiple threads and I want to see only the threads related to the bug that I care about when I'm working on something. > Right. I don't think Emacs has SOAP support at all. Could you have > your perl script dump out the XML structure, and perhaps Gnus could just > send that over "as is" to the server? package gnus I don't know how much of that xmlns cruft is actually required as opposed to just being default behavior. > On the other hand, scraping the HTML to find the bug numbers is really > easy. All the links are like > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50 > so it just has to get the HTML, look for "bug=[0-9]+", and there you > have it... Yeah, that might be easier than parsing the XML structure of the retured SOAP array when you don't have a SOAP library available to use. >> If you do this as an "article" per bug, you'd only have to fetch when >> someone actually read that article. > Gnus backends don't really support "deferred" fetching of stuff like > that... Didn't you just implement something sort of like that for nnimap? :) (I realize that it's a bit different and you probably don't want to have to enter something explicit to fetch the rest of the article, but it's a similar idea.) > I think one-group-per-component makes sense. I mean, the important > thing is that you can read all new comments on all the bugs you're > interested in, isn't it? If you have to take an extra step to inspect > each bug, it's kinda ... boring... Well, it depends on what you're using the backend for. Yeah, if you're just keeping up with bugs, that works, but generally some mailing list is subscribed to the bug traffic for a particular component anyway, so that's kind of uninteresting. I'd rather just read that traffic as a regular mailing list, which is going to be a fair bit faster since it's coming from my local mail server. I see the primary use of a dedicated backend as a way to go back and work on some previous bug, or catch up on a bunch of bug backlog that you didn't keep in your mail for some reason, in which case I think I'd want to work on one bug at a time. > Does the SOAP interface by any chance return more metadata -- like, for > instance, how many replies there have been to each bug, or the last time > it was updated, or anything else that can be used by nndebbugs to say > "no, I don't need to download that one, since I've already done so once > already". It returns some stuff: http://wiki.debian.org/DebbugsSoapInterface I think log_modified might be what you want. -- Russ Allbery (rra@stanford.edu)