Design issues for nntp storage manager

[Marco d'Itri]

On May 25, 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.
If you need it my innxmit patch works, but I stopped using dreaderd.

 >>  >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.
I think once you get into the right mindset, fetching articles by ID
allows way more flexibility than using (group,number).
It also allows you to not need overview on spool servers.

 >> 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?
Yes. Now I realize it's not such a good idea.

 >> 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.
As I wrote, diablo people did not find this important enough to
implement it. I think it should use the Xref server name as an hint, and
if the article is not found there look on other servers (for
redundancy).

 >> 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.
dreaderd uses a storage method similar to timecaf and does not use an
history file but just the overview DB, so it can be done. It does not
mind being fed the same article two times, as long as the Xref number is
the same.

-- 
ciao,
Marco