Idea for variation over tradspool

[bill davidsen]

In article <20010621104208.A6904 at student.dtu.dk>,
Preben Guldberg <c928400 at student.dtu.dk> wrote:
| 
| Not sure if this approach to improving tradspool has surfaced before.
| 
| Quoting storage/tradspool/README.tradspool:
| 
| > Currently the storage manager code works, although not perhaps as fast 
| > as it could.   The expiration code is somewhat unwieldy; since the storage
| > token does not have enough space to hold all the newsgroups an article 
| > is posted to, when expiration is done SMCancel() has to open the article
| > to find out what other newsgroups the article is posted to.  Eurggh. 
| > Suggestions for a better scheme are welcome. 
| 
| Concidering that the article number is stored as an unsigned long, I
| reckon that stealing a couple of bits to shift in extra information is
| feasible. For information on whether an article is crossposted and/or
| has an Expires: header, two bits are necessary.

During expire, I would expect the line from the history file to be
handy. If there is an Expires header the expires date would be set in
the field reserved for that in the history dates. That makes one bit go
away.

Now for my 2nd evil thought, if you really think this is worth doing to
avoid opening the article, you could save the information in the history
file (again) by hanging a leading zero on the posted date value. AFAIK
that's always going to be read as a decimal number, so it won't mean
anything to software which isn't using it.

So I guess one "that's already there" and a way to do it which follows
Plauger's Law of Least Astonishment for any existing software. You can
also have my (unsought) opinion that if you care about performance you
don't use tradspool.

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.