Read-Only applications prevent read-write DB access?
In the section How we initially intended to solve these problems there is a statement that reads:
some applications only need read-only access to the NSS configuration, but other applications (like Firefox, or Thunderbird) need read-write access. This means if a read/only user initializes first, then a read/write user will not be able to update the database.
The statement seems to suggest that separate applications affect each others' ability to open databases for read/write access. Surely that is not true with cert9 DBs, is it??
I think the section meant to say that, in a single application, if the first caller of NSS_Init opens it read-only, then the second caller cannot have read-write access. But that's not what it seems to say.
Binary compatibility means applications must continue to fail?
In the section Restrictions on any future solution Item 1) NSS must maintain binary compatibility, says NSS shutdown puts NSS into a state where it can NOT be re-initialized if it had slot references in use when it was shut down. It says that some applications that switch profiles depend on this behavior.
Is that a mistake?
Why count unique contexts?
Point 1 of the proposal says Multiple NSS_LibraryInit() calls are allowed. Each call will get it's own context. Point 3 of the proposal says NSS_LibraryShutdown() can be called once per context. If NSS_LibraryShutdown is called a second time on a context, an error is returned. But point 1 also says NSS will keep a count of NSS_LibraryInit calls. Why is a count of those calls necessary if each call gets its own unique context?
NSS_Init() semantics change after a call to NSS_LibraryInit() ??
Proposal point 2 says that, after the first time NSS_LibraryInit is called, subsequent calls to the older traditional NSS_Init functions change their behavior. I think this violates the principle of least astonishment. Well, that's an oversimplification, but I need to commit this now, and will expand on it later. This is probably the BIG issue!