[lsb-discuss] LSB conf call notes for 2008-09-10

[Jeff Licquia]

Nelson B Bolyard wrote:
> Jeff Licquia wrote, On 2008-09-12 06:35:
>> NSS/NSPR.
>> Ron: narrowed NSPR down to the bare minimum on the list.
>> Jeff: is that list in?
>> Mats: older list in, will probably shrink.
>> Ron: in snapshot?
>> Jeff: do we have spec for what we are keeping?
>> Mats: there's a pointer to upstream docs; looks like only one case of 
>> something missing, but need to check more.  If anyone concludes that they
>> want to use NSPR (as opposed to being forced to use it), they will be
>> disappointed.
>> Ted: what would people want from NSPR?  Could we create a sample app?
>> Mats: can create sample.  Very difficult to use the full lib if we
>> provide a stub.
> 
> What is meant by "provide a stub"?

The LSB SDK provides its own shared libraries for the purpose of linking 
applications.  They have no code, but provide the proper entry points, 
so when the app is run, the app links to the proper symbols in the full 
shared library.  This is what we call a "stub".

> What is being proposed/considered here?

Basically, we don't support full NSPR, just what NSS needs.  If someone 
wants to run NSS but can't because of something missing in our spec for 
NSPR, that's a bug we will fix in LSB 4.  If someone wants to use NSPR 
for any other purpose, they aren't going to be happy with what we're 
including.

Our usual answer when people want to use something outside the LSB is to 
recommend they bundle the library with the app.  That becomes a lot more 
difficult to do when we support only part of that library.

And Mats is recommending that we use a sample app to make sure we 
haven't missed anything.  If we can build a SSL-using app with our SDK 
and it works, then we have more confidence that we've got it right.

> NSS itself depends on a MUCH larger subset of NSPR's full API than the
> "bare minimum" set that is being discussed.  Anyone attempting to
> (re)implement a subset of NSPR would need to implement a MUCH larger set
> than the "bare minimum" for NSS to be able to function.
> 
> So, I wish to make sure that everyone is clear that this "minimum set" is
> not the minimum set of NSPR functions that must be implemented for NSS to
> work, but rather is (intended to be) the minimum set that an application
> program (or library) would need to use NSS for SSL.

In general, we don't care what the library itself needs; that's an 
implementation detail.  The application, and what it needs, is our full 
focus.

So as long as we've got all the NSPR stuff that apps using NSS need to 
call directly, we should be OK.

> Jeff, thanks for the great minutes!

You're welcome.  As always, corrections or clarifications to the minutes 
are appreciated.