Howard Chu wrote, On 2008-08-11 20:07:
> Nelson B Bolyard wrote:
>> Howard Chu wrote, On 2008-08-10 14:13:
>
>>> It would make it impossible to use in e.g. OpenLDAP/nss_ldap because
>>> applications would be unable to load their own configuration settings
>>> after nss_ldap/libldap/nss initialized.
>> Nothing prevents each application from having its own configuration.
>> Nothing prevents an application from changing its configuration while it
>> is running. Not even with cert8.db files.
>
> I've been studying this some more; I still don't see a
> clean/backward-compatible solution for this situation:
>
> 3rd party library "foo" calls NSS_Init("my path") and expects the DB files
> from "my path" to be used.
>
> Mozilla browser calls NSS_Init("profilepath") and expects the DB files from
> "profilepath" to be used.
>
> If the browser calls some other library that triggers foo, the DB in effect
> depends on which NSS_Init call came first. One or the other of these two
> pieces of software is going to break. There's no way for any software to
> detect that NSS_Init was called already,
Except for calling this function:
PRBool NSS_IsInitialized(void);
Rest snipped, since it was based on the assumption that "there's no way".
The next question to ask is: if a library finds out that NSS is already
initialized, what function does it call to register additional modules
that may use additional resources (potentially additional DBs)?
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
