Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: tradspool tooken weirdness (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 Dec 2023 07:34:43 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: tradspool tooken weirdness
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 156, Issue 5
*******************************************
