Idea for variation over tradspool

Russ Allbery rra at
Thu Jun 21 11:26:23 UTC 2001

Preben Guldberg <c928400 at> writes:

> 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.

Hm.  Yeah, that's an interesting thought.

> For the stored article on disk, I decided to add an extension - an octal
> number reflecting the bits stored in the token above. This way, by
> inspecting the article name, it should be evident whether an article is
> crossposted or have an Expires: header. This should generally reduce the
> number of times actual opening of an article is required.

I'm not sure there's much utility in picking up a spool storage method
that's *almost* traditional spool.  One of the major features of
traditional spool is that it can be used with the huge amount of existing
software that already understands the spool format, and that software
would be confused by this change.  The other storage methods have
significant benefits that tradspool don't have.  (Although one file per
article that can be easily found *is* nice and only tradspool has that.)

> While coding, I split functions common to tradspool and tradext
> (traditional spool with extensions/extended tradspool) from tradspool.c
> into trad.h (residing in the tradspool directory), similar to the
> approach with timecaf.

> If anyone is interested, where should I send the files? Since it is 20K
> in a patch and two tarballs, I didn't feel comfortable just sending it
> to the list.

You can send them to me; the splitting of things apart at the very least
would probably be useful.

> Btw, changes are against a inn-CURRENT-20010615, but there seem to be no
> changes in any of the files as of inn-CURRENT-20010620?

There hasn't been much committed lately, but I've just landed a bunch of
stuff tonight.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list