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. NNTPS pointers (Grant Taylor)
2. Re: INN indentation (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Oct 2021 13:44:11 -0600
From: Grant Taylor <[email protected]>
To: INN Workers <[email protected]>
Subject: NNTPS pointers
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
Does anyone have quick pointers how to get INN to support NNTPS for
server-to-server peering?
I've got NNTPS working for NNRP but now I'm trying to add it for NNTP.
I took a swing at it a couple of weeks ago but didn't make much
progress. I'd like to avoid hacks like stunnel if at all possible as I
want INN to see the remote peer's real IP address.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211018/ec1e3c88/attachment-0001.bin>
------------------------------
Message: 2
Date: Mon, 18 Oct 2021 23:58:38 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> It seems like that all inclusions of "clibrary.h", or of both "clibrary.h"
>> and "config.h", should be changed to only one inclusion of
>> "portable/system.h".
>> And "clibrary.h" moved to "portable/system.h".
>
> I think that's right.
Change done.
> That reminds me that I want to take a moment now that everything is in Git
> and switch the INN build system over to Automake, since I think it would
> get rid of a bunch of maintenance gotchas and chores that currently have
> to be done manually. It will raise a few questions, though, such as
> whether the additional human-readable information in MANIFEST is useful
> when it's no longer necessary to generate a distribution.
I am unsure people really look at the MANIFEST...
We can get rid of it if no longer useful to pick up the right files to
include in a release.
>> I think the namespace is ok (I'm not aware of any complaints about it).
>> Unless I am missing something, there isn't any work to do for that task,
>> is it?
>
> So, the problem with the namespace is that we create a shared library that
> has tons of random functions exported from it that don't share any common
> prefix, and hence sprawl all over the C function namespace. (Stuff like
> concat, all the buffer_* stuff, etc. Often they have their own namespace,
> like QIO, but sometimes they don't nad it's not really consistent.
Understood, thanks.
> For a well-behaved shared library, ideally all that stuff should have inn_
> or INN_ prefixes. But that's a huge pain in the ass to do because it's
> little changes all over the source base, and I'm not sure if it's a good
> use of time. This is part of why, for example, the Debian packages
> install the libinn shared library out of the normal library search path,
> since it's not entirely a well-behaved shared library. (Also it doesn't
> have symbol versioning.)
>
> Another approach rather than rename everything would be to shrink the
> symbols provided by the shared library down considerably to only things
> that make sense for external programs seeking to have API access to INN
> data files, namespace all of those, and then hide all the other symbols.
> This would probably involve creating a separate static library with the
> internal utility code like buffer and linking that with all the
> executables. This is what I do for other projects with a shared library
> to keep the shared library ABI minimal. Again, not sure it's worth it,
> and it would break any out-of-tree software that really uses libinn for
> its random utility functions.
Sounds like a great amount of work, with no real direct benefit...
>> Time has come to get rid of "inn/defines.h" at the same time,
>> and just include the necessary headers instead of it.
>
> Yup, that would be great.
Also done.
--
Julien ?LIE
??Il est difficile de discuter avec des gens qui ne peuvent pas entendre
et qui ne veulent pas entendre.?? (Julius Welhausen)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 7
*******************************************
