[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