home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!iadpsa!iowegia!kjhoule
- From: kjhoule@iowegia.uucp (Kevin Houle)
- Newsgroups: comp.bbs.waffle
- Subject: Re: News/mail reader
- Message-ID: <Jo5FuB3w165w@iowegia.uucp>
- Date: Wed, 18 Nov 92 11:49:06 CST
- References: <1992Nov17.150618.21522@morpheus.bssi.bls.com>
- Distribution: world
- Organization: Iowegia Public Access Usenet/UUCP, Clive IA USA.
- Lines: 40
-
- dawson@morpheus.bssi.bls.com (Willard Dawson) writes:
-
- > Methinks Kevin has overlooked this problem?
-
- What problem? There isn't one as long as..
- 1] before unbatching, there are no duplicates in the directory
- 2] duplicates are removed immediately after unbatching, before
- the articles can be read and batched.
-
- > Let's suppose you have 1000 users, each of which is subscribed to all of
- > Usenet, plus a few alt groups, and maybe some local groups. How about
- > 1000 lines per join file... gee, that's 1,000,000 lines to reset, each
- > time you resequence the articles.
-
- You are looking too far downstream in the process and assuming there
- IS a problem. Let's take the example of a news directory containing
- the article numbers...
-
- Before unbatching : 10, 11, 12, 13, 14, 15
- After unbatching : 11, 12, 13, 14, 15, 16, 17, 18, 19
-
- One article was expired for effect. We know articles 11-15 are
- unique. Since the logic of duplicate removal keeps the first of
- any two duplicates, 11-15 will still be there after duplicate
- removal and any resequencing. And if all 1000 users have read all
- articles in that particular group, their pointers are sitting at
- 15. Maybe article 17 is a duplicate.. we get a resequencing of
- 18->17 and 19->18. Looks like this now..
-
- After dup. deletion and resequencing : 11, 12, 13, 14, 15, 16, 17, 18
-
- Join pointer is still at 15, which is correct. So where is the problem?
-
- > That sounds like a lot of work, and I believe is all really quite unnecessary
-
- Sounds rather simple to me.
-
-
- --
- Kevin Houle kjhoule@iowegia.uucp
-