Re: tradspool tooken weirdness

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

All right, it would indeed be better to have a homogenized syntax for 
tradspool tokens between 32 and 64-bit archs.

The only drawback I see if we enforce uint32_t instead of unsigned long, 
is that it is not in the path towards supporting 64-bit article numbers 
(but well, that's another story and amount of work globally in INN).  At 
least it would make consistent the generation of 32-bit article numbers 
in tradspool tokens, but while we're at doing a migration, why not use 
uint64_t instead for article numbers?  (group numbers may be kept as 
uint32_t)


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

I would prefer not oblige users to rebuild their history on upgrade.


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

Seems like the better way.  When news.daily regenerates the history 
file, these tokens can indeed be fixed.

-- 
Julien ÉLIE

« Dans toute statistique, l'inexactitude du nombre est compensée par la
   précision des décimales. » (Alfred Sauvy)
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers