Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote: > > * 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 > > So they have always been bad at providing an API, not just now, or that > their web content disappeared and they haven't fixed it, for how long? > I guess that is better than the v8 case, but not much. Is posting web > content really that hard for them?
To be clear, *part* of the web-based documentation disappeared and hasn't been replaced yet. The NSS-specific pieces are actually still available, it's the NSPR (which is a lower level library used by NSS) part that was removed from MDN and hasn't been brought back yet, but which does still exist as comments in the source of the library. > > 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. > > I have no specifics. Then I don't understand where the claim you made that "it seems to mean they want to maintain the ability to change it at any time" has any merit. > > > 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. > > Wow, you have a much higher tolerance than I do. How do you even know > which functions are the public API if you have to look at the source > code? Because... it's documented? They have public (and private) .h files in the source tree and the function declarations have large comment blocks above them which provide a documented API. I'm not talking about having to decipher from the actual C code what's going on but just reading the function header comment that provides the documentation of the API for each of the functions, and there's larger blocks of comments at the top of those .h files which provide more insight into how the functions in that particular part of the system work and interact with each other. Maybe those things would be better as separate README files like what we do, but maybe not, and I don't see it as a huge failing that they chose to use a big comment block at the top of their .h files to explain things rather than separate README files. Reading comments in code that I'm calling out to, even if it's in another library (or another part of PG where the README isn't helping me enough, or due to there not being a README for that particular thing) almost seems typical, to me anyway. Perhaps the exception being when there are good man pages. > I frankly think we need some public statement from the NSS developers > before moving forward --- there are just too many red flags here, and > once we support it, it will be hard to remove support for it. They have made public statements regarding this and it's been linked to already in this thread: https://github.com/mdn/content/issues/12471 where they explicitly state that the project is alive and maintained, further, it now now also links to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1753127 Which certainly seems to have had a fair bit of action taken on it. Indeed, it looks like they've got a lot of the docs up and online now, including the documentation for the function that started much of this: https://firefox-source-docs.mozilla.org/nspr/reference/pr_recv.html#pr-recv Looks like they're still working out some of the kinks between the NSS pages and having links from them over to the NSPR pages, but a whole lot of progress sure looks like it's been made in pretty short order here. Definitely isn't looking unmaintained to me. Thanks, Stephen
signature.asc
Description: PGP signature
