Latent bug in the new tradindexed code?

[Alex Kiernan]

On Wed, 2002-09-18 at 06:29, Russ Allbery wrote:
> 
> Katsuhiro Kondou <Katsuhiro_Kondou at isc.org> writes:
> 
> > I'd want to avoid further data copying at nnrpd, and this is why I wrote
> > such API.
> 
> Do you have a feel for how much it's saving in terms of time?  I have a
> sneaking suspicion that it might actually be pretty noticable, but I
> haven't done any performance metrics.
> 

How about if we had an interface which went something like this:

OVopensearch(...) // sets the parameters for the search
OVsendoverview(handle, fd, virtualdomain)

Within the overview support library we then implement something which
the underlying overview mechanisms can punt to if they decide they can't
optimise the delivery of the overview, in particular we can put the
virtual domain handling in there so we don't have to have the code in
two places (article.c in nnrpd and the overview support library). I
guess though if you had a real database for overview, handling the
virtual domain case yourself may be easy too.

Not sure how you'd fit it together with the current rate limiting
though.

> The more I think about it, the more I think that the current tradindexed
> declaration is okay, even though it's not strictly correct.  I think the
> only case where you get into trouble with the current declaration is if
> you're using the cache, and the cache is disabled for read-only access
> (it's only used for writing).
> 

I didn't really try & follow the code, I just spotted it looked odd :) 

I'll try to remember to update the overview docs to include something on
OVSTATICSEARCH.

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc