Re: nnweb + Gmane search

[Olly Betts <olly@survex.com>]

Andreas Seltenreich <andreas+ding@gate450.dyndns.org> writes:
> Great, would it be okay to just set HITSPERPAGE to nnweb-max-hits and
> doing a single request per search? One could also decrease the default
> upper bound of 999 articles, but if this really is an issue, it would
> be better to hardcode a limit for the Gmane part of nnweb, since
> nnweb-max-hits is a user-customizable variable.

I've just tried fetching 1000 matches, and it typically takes several
seconds (note that the "search time" is printed before the records
are read so it under-reports in this case).  

If this proves to be a problem I can easily impose a lower limit on the
server though.

> It wouldn't have to be complete, just enough to present the hits to
> the user plus something in the xref header one can construct links to
> the raw articles from. Currently, nnweb parses the html output and
> generates nov-lines like the following:

Anything you can produce from the HTML output I can produce on the server
of course.

> > Other output formats aren't hard to add, but require me to update
> > two places if anything changes so are a bit more work to support. So
> > I'd prefer something more generic than S-exps.
> 
> Now, does "more generic than S-exps" apply to nov-lines ?

I think so.  NOV is really just tab-separated fields.
dd  Just don't be tempted to work around by running more
searches to fetch 999 if I do...

How does this first attempt look:

http://search.gmane.org/cgi-bin/omega.cgi?FMT=nov&query=gnus+nnweb

The first line is either an error, or:

OK <total (estimated) matches> <number of matches which follow> <match time>

Beware the extra blank line at the end (which is hard to avoid right
now).  And note that encrypted addresses will be missing the
"@public.gmane.org" (because that's how they're stored internally to
save space).

Beware the URL and format may not be stable, so don't build it into
anything just yet.  

Cheers,
    Olly