tradspool tooken weirdness

[Christoph Biedl]

Julien ÉLIE wrote...

> Hi Christoph,
> 
> > Nicer was to make the
> > implementation follow the design, replace unsigned long with uint32_t
> > when it's about article and group numbers[1], and have a transition in
> > the lookup code for the article number. It would check both offsets (4
> > and 8), the non-zero one has the actual information. That might as
> > well be done as part of an upgrade.
> 
> Why would there be a need for a transition?
> On a given server, there won't be mixed tokens (ones with 32-bit long
> numbers and others with 64-bit long numbers), and the history file needs
> rebuilding when doing such a change of architecture or enabling/disabling
> largefile support.
> When would we have a case of mixed tokens like that in a history file, and
> "sm -c" failing to decode some of them?

No architecture switch, all this was within amd64 (or other 64 bit
archs).

Assuming INN was modfied to create and parse the tokens as specified.
Then the upgrade brings a problem as the existing tradspool tokens
become invalid.

To deal with this, I can think of

* Big warning in the release notes a history rebuild is needed during
  upgrade when using tradspool
  Pro: Not much work
  Con: Hazzle for the users, some will forget this and be annoyed
  afterwards.

* Extra code that deals with these invalid tokens by picking the article
  number from the place where it is. That the transition I was talking
  about.

* Additionally, the next news.daily could repair these invalid tokens as
  well.
  Pro: The handling of invalid tokens could be removed again faily soon,
  say after the next major release.

Hope that makes my thoughts a bit more clear. I prefer clean solutions
even if they mean more work (here: Create tokens as specified) over
quick hacks (which give me a bad feeling for all the time that follows).

    Christoph