Re: [NNTP] Article Numbers Becoming Invalid (RFC 3977)
"Charles Lindsey" <[email protected]> Mon, 4 Jan 2010 12:07:04 GMT
| Newsgroups | gmane.ietf.nntp |
|---|---|
| Message-ID | <[email protected]> |
In <[email protected]> Russ Allbery <[email protected]> writes: >Julien ÃLIE <[email protected]> writes: >> OK, I understand. >> However, such an implementation is difficult on distributed servers >> (a common active file or different readers/storage servers). The reader >> would have to be able, when it receives a GROUP command, to update the >> active file, which can be maintained in another server. >> As the low water mark cannot decrease, LIST ACTIVE, LIST COUNTS, GROUP >> and LISTGROUP have to use similar low water marks. But does "similar" necessarily meant "identical"? >Yes. And while for LISTGROUP it would be feasible for a standalone server >to do the same thing, it really isn't feasible to update the low-water >mark in LIST ACTIVE for every cancelled article in the news server >implementations that I'm familiar with. (They could, of course, be >redesigned to do this, but it doesn't seem like a good use of time and the >problem around distributed servers is very tricky.) But it seems we are still expecting GROUP to report the best LWM available to that particular server at that instant, which may be higher than what LIST ACTIVE just reported (and may be out of date again 10ms later :-( ). But normally if the client asks for that ARTICLE "immediately" after the GROUP command he should expect to get it. >> With the as-if principle, it then allows a server to say the low water >> mark is 10 whereas the first existing article is 12. >> Therefore, after GROUP, 10 is the current article and ARTICLE answers 420. >> As the current article is required to point to the reported low water mark, >> it cannot be set to 12. >Yes, or the result of GROUP would be inconsistent with LIST ACTIVE, and >specifically LIST ACTIVE could report a lower number than a previous GROUP >command, which isn't allowed. (It's not allowed for reasons that don't >really apply here, but still.) But it is clear just that is going to happen with all reasonable implementations, so we need to ask whether it really matters. What evil then ensues? AFAICS nothing, because a subsequent GROUP will always report something not less than the previous GROUP. So what are the "reasons that don't really apply here", and can we think of a plausible excuse for ignoring them? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5