Re: nndebbugs

[Russ Allbery <rra@stanford.edu>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Russ Allbery <rra@stanford.edu> 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?

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <get_bugs xmlns="Debbugs/SOAP/1">
      <c-gensym3 xsi:type="xsd:string">package</c-gensym3>
      <c-gensym5 xsi:type="xsd:string">gnus</c-gensym5>
    </get_bugs>
  </soap:Body>
</soap:Envelope>

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)             <http://www.eyrie.org/~eagle/>