Re: ietf-nntp Backfill
Taz Higgins <taz@taz.compulink.co.uk> Tue, 17 December 1996 14:36 UTC
Received: from cnri by ietf.org id aa26760; 17 Dec 96 9:36 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa11235;
17 Dec 96 9:36 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id
IAA04158 for ietf-nntp-outgoing; Tue, 17 Dec 1996 08:33:24 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to
owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by
academ2.academ.com (8.8.3/8.7.3) with ESMTP id IAA04153 for
<ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 08:33:22 -0600 (CST)
Received: from jareth.sesqui.net (JARETH.SESQUI.NET [128.241.0.93]) by
academ.com (8.8.3/8.7.1) with ESMTP id IAA14417 for <ietf-nntp@academ.com>;
Tue, 17 Dec 1996 08:33:20 -0600 (CST)
Received: from mail.compulink.co.uk (mail.compulink.co.uk [194.153.0.20]) by
jareth.sesqui.net (8.7.1/8.6.9) with ESMTP id HAA16868 for
<ietf-nntp@academ.com>; Tue, 17 Dec 1996 07:44:28 -0600 (CST)
Received: from taz (taz.compulink.co.uk [194.72.181.105]) by
mail.compulink.co.uk (8.8.4/8.6.12) with SMTP id NAA03227;
Tue, 17 Dec 1996 13:41:20 GMT
Date: Tue, 17 Dec 1996 13:37:36 GMT
X-Mailer: Virtual Access by Ashmount Research Ltd
Message-Id: <VA.0000033c.00031dce@taz>
To: clive@demon.net
Cc: ietf-nntp@academ.com, taz@taz.compulink.co.uk
Subject: Re: ietf-nntp Backfill
From: Taz Higgins <taz@taz.compulink.co.uk>
Reply-To: taz@taz.compulink.co.uk
Organization: Ashmount Research Ltd
In-Reply-To: <K$FX2JA30AsyEwSv@on-the-train.demon.co.uk>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk
As another client author (Virtual Access), backfilling is a complete and utter pain at the server end. Article numbers are monotonically increasing and unique. Anything else causes more queries and information to have to be sent by both client and server to cope with the variety of cases - this is to my mind "a bad thing" if no "a very bad thing" to address the points clive raised > [Q1] When a group becomes the current group, is the set of articles made > available to the client fixed at that moment ? Yes. I would expect to look for artie numbers withing that range only. > [Q2] When will new articles become available and expired/cancelled ones > become unavailable ? Is it: > - not until a new NNTP session > - next time the group is made the current group after another group > has been the current group > - next time the group is made the current group, whether or not it I wouldn't expect that any article in the range would be there - the only ones that I might still expect to be there are the min and max articles - but even then I wouldn't assume so I wouldn't assume a client process such as reading articles could stop a server from expiring/cancelling articles repeatedly doing next's I wouldn't be surprised for more articles to appear with a number greater than that returned by group - although we'd stop asking at that point > [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 Yes - but only as it is the same article, otherwise article numbers must be unique > 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: > > Q3 Q4 Q5 > Monotonic Y N N > Backfilling Y N Y > Wind-back Y Y Y > > Servers appear to exist of all three kinds, but all clients I am aware > of that use article numbers at all are monotonic VA is monotonic > 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. Given this, > there seems little reason to require that servers be monotonic I disagree strongly on this point - the read/unread status of an article is NOT stored on the server - that is a property of the client and it's display. The server would have to store a list of what articles had been read by what client - this would add to the servers load tremendously - take a look at COmpuServe which does this, it's one of the reasons compuserves forums can be slow Articles can be pulled one by one as specified by the client using the references - let the client worry about this -- Taz Higgins of Ashmount Research Virtually Accessing the Net with V I R T U A L A C C E S S
- ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Jon Ribbens
- Re: ietf-nntp Backfill Rich Salz
- Re: ietf-nntp Backfill Richard Clayton
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Nat Ballou
- Re: ietf-nntp Backfill Brian Kantor
- Re: ietf-nntp Backfill markd
- Re: ietf-nntp Backfill Rich Salz
- Re: ietf-nntp Backfill Stan Barber
- Re: ietf-nntp Backfill USENET news manager
- Re: ietf-nntp Backfill Chrisy Luke
- Re: ietf-nntp Backfill Taz Higgins
- Re: ietf-nntp Backfill Nat Ballou
- Re: ietf-nntp Backfill Chris Lewis
- Re: ietf-nntp Backfill Chris Caputo
- article numbers (was Re: ietf-nntp Backfill) Chris Newman
- Re: ietf-nntp Backfill Brian Kantor
- Re: ietf-nntp Backfill Chris Newman
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Clive D.W. Feather
- Re: ietf-nntp Backfill Jack De Winter
- Re: ietf-nntp Backfill Chris Hall
- Re: ietf-nntp Backfill Mark Sidell
- Re: ietf-nntp Backfill Alan Barrett