Re: ietf-nntp Backfill

[Jon Ribbens <[e-mail]>]

I am looking at INN 1.4 for this reply.

Clive D.W. Feather wrote:
> [Q1] When a group becomes the current group, is the set of articles made
> available to the client fixed at that moment ?

Yes and no. The list of article numbers available is fixed at the
moment you execute 'group'.

> [Q2] When will new articles become available and expired/cancelled ones
> become unavailable ? Is it:

New ones will become available and deleted ones will become unavailable
immediately. However 'NEXT' will not attempt to show deleted articles,
and it will not attempt to show newly-arrived articles. This seems
reasonable to me.

> Note that an answer of "yes" to Q1 means that NEXT and LAST move each
> way consistently along a fixed list, *but* it also requires that expired
> or cancelled messages remain available while the group is current.

NEXT and LAST do use a fixed list, but deleted articles do not
remain available. This seems okay.

> If the answer to Q1 is "no", then this implies that articles can appear
> or disappear during a single NNTP session.

I guess the answer is 'no' then.

> [Q3] Can an article appear with a number higher than the previous
> maximum, such as 1357 ? Obviously the new maximum would be higher.

Yes.

> [Q4] Can an article appear with a number less than the previous minimum,
> such as 1111 ? Obviously the new minimum would be lower.

No.

> [Q5] Can an article appear with a number between the previous limits,
> such as 1250 ?

No.

> [Q6] Can the lowest numbered article disappear ? Obviously the minimum
> would increase if necessary.

Yes.

> [Q7] Can the highest numbered article disappear even though a lower
> numbered article (such as 1266) remains ? Obviously the maximum would
> decrease if necessary.

Yes.

> [Q8] Can any other article disappear even though a lower numbered
> article remains (e.g. 1266 disappearing with 1234 remaining) ?

Yes.

> [Q9] If an article disappears, can it ever reappear again ? The same
> article, this is, not a new article given the same number by the server,
> which we all assume is not permitted.

This would not appear to happen in general, but it seems reasonable
to allow it.

> There are three common scenarios posited for NNTP clients and servers. I
> call these "monotonic", "backfilling", and "wind-back". They answer the
> first three questions:

Wind-back?

> Servers appear to exist of all three kinds,

Is there more than one site in existance which uses backfilling?

> but all clients I am aware of that use article numbers at all
> are monotonic.

Indeed.

> A sensible client needs to allow for the user wanting to mark articles
> as unread. Therefore it must be able to cope with the backfilling
> strategy, by (for example) maintaining a list of ranges.

No. An unread article and an unavailable article are not the same
thing.

> Given this, there seems little reason to require that servers be
> monotonic.

Given that almost every news client in existance requires that
servers be monotonic, I would suggest that it would be a very
good idea for the new NNTP specification to require it too.

As noted elsewhere, even 'rn' requires that servers be monotonic.

> On the other hand, there are advantages to the answer to Q4 being "no".
> If it is, then it is possible to forget everything about articles with
> numbers below the current minimum. This ensures that historical
> information with no current use can be eventually thrown away.

There are 'advantages'!? Surely you mean 'it is essential that the
answer to Q4 be "no"'? Otherwise, due to the occasionaly cancelled
article and so on interrupting the numbering range, the news client
must maintain a list of ranges which grows without bound.

Not only this, but on every connection it must explicitly check
for every article not found before, in order to produce a valid
display of available articles.

So if the answer to Q4 is not 'no', the user's 'newsrc' (or
whatever) file will always grow larger over time, and every
connection to the news server will be slower than the last.
After a year or so I imagine the newsreader would be quite
unusable (or maybe even after only a couple of months). The
newsreader *must* have some mechanism of saying "well, this
article is never going to turn up now, I don't need to worry
about it any more".

Backfilling is not necessary, no widely used servers do it,
most, perhaps all widely used clients require it not to happen.
It is a Bad Thing. RFC 977 did not allow it, but if people
are going to quibble then the new RFC should explicitly
disallow it. It should be possible to fetch news without
recourse to heuristics.

Cheers


Jon
____
\  //    Jon Ribbens    //
 \// [e-mail] //