Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote: > > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I > > think the upstream source. > > > > A project without even a bare-minimal README at the root does have a > > "internal > > only" feel to it... > > I agree --- it is a library --- if they don't feel the need to publish > the API, it seems to mean they want to maintain the ability to change it > at any time, and therefore it is inappropriate for other software to > rely on that API.
This is really not a reasonable representation of how this library has been maintained historically nor is there any reason to think that their policy regarding the API has changed recently. They do have a documented API and that hasn't changed- it's just that it's not easily available in web-page form any longer and that's due to something independent of the library maintenance. They've also done a good job with maintaining the API as one would expect from a library and so this really isn't a reason to avoid using it. If there's actual specific examples of the API not being well maintained and causing issues then please point to them and we can discuss if that is a reason to consider not depending on NSS/NSPR. > This is not the same as Postgres extensions needing to read the Postgres > source code --- they are an important but edge use case and we never saw > the need to standardize or publish the internal functions that must be > studied and adjusted possibly for major releases. I agree that extensions and public libraries aren't entirely the same but I don't think it's all that unreasonable for developers that are using a library to look at the source code for that library when developing against it, that's certainly something I've done for a number of different libraries. > This kind of feels like the Chrome JavaScript code that used to be able > to be build separately for PL/v8, but has gotten much harder to do in > the past few years. This isn't at all like that case, where the maintainers made a very clear and intentional choice to make it quite difficult for packagers to pull v8 out to package it. Nothing like that has happened with NSS and there isn't any reason to think that it will based on what the maintainers have said and what they've done across the many years that NSS has been around. Thanks, Stephen
signature.asc
Description: PGP signature