Design issues for nntp storage manager

Alex Kiernan alexk at demon.net
Fri May 25 08:53:53 UTC 2001


Thanks for the response (and sorry for the delay - why is that just as
you ask this kind of question everything else conspires to not let you
back near it for a week?)

"Marco d'Itri" <md at linux.it> writes:

> On May 15, Alex Kiernan <alexk at demon.net> wrote:
> 
>  >The header only feed bit is straightforward, but figuring out what the
> (Do you have an innfeed version capable of headers feed now?)
> 

Not yet.

>  >nntp storage manager token should look like is causing problems.
> I'm not sure I understand your question. Why you do not want to request
> the articles by Message-ID like dreaderd does?

I wanted to be able to drop it in, without having to change the
existing nnrpd, so implementing it as yet another storage manager
seemed the way to go.

One approach would I guess be to add the message ID to the list of
parameters passed to SMretrieve, the SM can then use whichever it
wishes.

>  >Both have the issue of storing which article server a message is
>  >stored on (but thats probably easy to throw into the token somehow
>  >like cnfs does).
> dreaderd does not know the origin of an article and just asks all the
> known spool servers in the selected order, and in practice this works
> well enough nobody cared implementing something better.
> I think the most versatile implementation would do a first match of the
> newsgroup name against a list of wildmat patterns like:
> 
> alt.*:alt-spool.news.isp.net
> alt.binaries.*:bin-spool.news.isp.net
> *:text-spool.news.isp.net
> 

Unless I'm missing something, you still need to poll every server if
someone requests the article by message id?

> And optionally support something like:
> 
> pattern.*:XREF
> 
> which means "look at the Xref header and request the article from that
> server".
> 

Surely thats what you do by default - if I have the article in my
overview database, then someone must have fed the headers to me.

>  >A hook to rewrite the history for whole articles we received when they
>  >got overwritten in a cnfs can would be needed (but not during expire,
>  >I think).
> In the diablo/dreaderd model readers do not have an history, and I think
> this is very convenient.
> 

But I'd quite like to be able to cache articles in a local CNFS can,
which means we need the history file. I'd also like to be able to
pre-feed some articles (say highly read local groups).

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC


More information about the inn-workers mailing list