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)
2. Re: [PATCH 0/4] Improve delayer (Julien ?LIE)
3. Re: [PATCH 0/4] Improve delayer (Christoph Biedl)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Jan 2024 19:41:55 +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,
>> We discussed a MAXARTNUM capability to
>> achieve that in December 2022 in news.software.nntp:
>>
>> <[email protected]>
>> https://groups.google.com/g/news.software.nntp/c/4_KjHu9GlBg
>
> Will read the entire discussion later. Personally, this idea gives me a
> bad feeling for introducing some complexity instead for just forcing the
> clients to deal it with. But possibly this has already been voiced and
> discussed.
The problem for "just forcing the clients" to deal with 64-bit article
numbers, is that the NNTP protocol does not allow that. Article numbers
MUST be < 2^31.
So we can't just force clients to accept more, and let servers send such
large numbers.
We would either need an update to RFC 3977 and define NNTP Version 3
(with maybe other changes at the same time). Servers would then either
advertise Version 2 and/or 3, and behave differently depending on the
client (which would probably have to advertise the version number it
supports, by for instance announcing it as a keyword to CAPABILITIES, or
any other way we would standardize in Version 3). Well, that will be
some work to do.
That's the reason why a simpler capability, compatible with RFC 3977, is
proposed. Unless the client advertises the maximum article number it
supports, the server does not send such article numbers and cope with
RFC 3977. Note that Clive Feather, author of that RFC, already had that
in mind (with the BIGNUM extension) but it was not explored more by the
IETF working group, probably by lack of time or energy (there was
already a lot of work to do with all the NNTP specifications at that time).
>>> On the other hand, there's the main lesson from y2k and upcoming
>>> y2038: Software will be used for way longer times and at way bigger
>>> scale than initially anticipated - therefore adapt early.
>>
>> As you're speaking about y2038, there's an open bug to support the upcoming
>> 64-bit time_t transition for 32-bit archs that some distributions plan to
>> do:
>> https://github.com/InterNetNews/inn/issues/292
>> https://wiki.debian.org/ReleaseGoals/64bit-time
>>
>> The CAF file header should be converted to use uint64_t instead of time_t
>> (as well as size_t and off_t). Otherwise 32-bit system upgraded to 64-bit
>> time_t won't be able to retrieve old articles from a timecaf news spool.
>
> Possibly this should indeed be done in a huge batch of fixing 32/64 bit
> issues. However, while tempting, my schedule is pretty full, so don't
> expect me to work on this any time soon, sorry.
No problem, you don't have to be sorry. I totally understand! (I too
do not have unlimited time to work on INN.) I was just pointing at that
ticket, just in case :)
--
Julien ?LIE
??? Tu parles??
? Tu parles?!?? (Ast?rix)
------------------------------
Message: 2
Date: Thu, 18 Jan 2024 19:42:18 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [PATCH 0/4] Improve delayer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Christoph,
> Warning, the output buffering done by delayer can easily cause some
> confusion.
I was a bit mistaken by that. Thanks for having taken the time to
verify how that works.
> Good news, a stand-alone test is very easy to do. For better visibility,
> I recommend the ts (timestamping) program as it prefixes each input line
> with a timestamp.
I did not know ts. Thanks for the pointer to it; I'll remember it and
will surely use it for future testing.
> $ (
> sleep 3 ; echo 'art1' ;
> sleep 56 ; echo 'art2' ;
> sleep 3 ; echo 'art3' ;
> sleep 58 ; echo 'EOF'
> ) | perl contrib/delayer.in --delay 60 --no-buffered -- ts -s
> 00:01:03 art1
> 00:01:59 art2
> 00:02:00 art3
> 00:02:00 EOF
>
> The first two lines are delayed by 60 seconds as desired, the third not
> because everything is flushed at end of input.
That's fine.
> Also, it's not necessary to have another input to trigger output, that
> was a misunterstanding on my side. So please drop the lines
>
> +Still a line is not sent to output until another line is read from the
> +input.
OK, I'll remove that sentence.
--
Julien ?LIE
? Personnellement, j'adore passer du temps ? ne rien faire ; mais pas
n'importe quand. ?
------------------------------
Message: 3
Date: Thu, 18 Jan 2024 21:44:23 +0100
From: Christoph Biedl <[email protected]>
To: [email protected]
Subject: Re: [PATCH 0/4] Improve delayer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE wrote...
> OK, I'll remove that sentence.
As I learned in IRC, there is need for another correction in the 'Add
documentation' commit,
+ ctlinnd begin innfeed-delayed
should rather be
+ ctlinnd begin 'innfeed-delayed!'
(Exclamation mark was missing, quotation marks to proected that from the
shell expansion.)
Christoph
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 157, Issue 12
********************************************
