[lsb-discuss] [Fwd: NSS public functions]
Howard Chu
hyc at symas.com
Mon Aug 11 13:55:26 PDT 2008
Jeff Licquia wrote:
> Howard Chu wrote:
>> Since NSS is inextricably dependent on NSPR, the inclusion of NSS in the LSB
>> implies that NSPR must also be in the LSB. No?
>
> Not unless reference to NSPR must be made in the source code of the
> application to use NSS (or, at least, the portion of NSS that we specify).
>
> If the dependency is hidden, then we consider that to be an
> implementation detail.
>
In fact it's impossible to write an NSS app without also making numerous
direct calls to NSPR. From this same page:
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslintro.html
>>>
Configuration
PR_NewTCPSocket. ... A legal NSPR socket is required ...
Communication
A server application typically uses these functions to establish a connection:
PR_Bind
PR_Listen
PR_Accept
PR_GetSockName
A client application typically uses these functions to establish a connection:
PR_GetHostByName
PR_EnumerateHostEnt
PR_Connect
PR_GetConnectStatus
<<<
Note - apps that use NSS generally cannot use OS-native calls for these
extremely standard functions (including I/O and memory management). Instead
they must use NSPR calls. This extra abstraction layer offers no benefit on
Linux, it just increases overhead and application footprint. I believe
NSS/NSPR are a poor choice upon which to build in the Linux environment. The
net result would be like running a POSIX emulation machine on top of Linux -
totally redundant, wasteful, and inefficient.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
More information about the lsb-discuss
mailing list