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

[Nelson B Bolyard]

Jeff Licquia wrote, On 2008-09-12 12:12:
> Nelson B Bolyard wrote:

>> 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".

Thanks for that explanation.  It sounds to me as if LSB will provide
something similar to what MS Windows calls an "import library", a
surrogate for the real shared library, used only for linking in other
libraries or executables, something not historically required on Unix-ish
platforms.  I hope you won't mind if I use the term "import library" for
these stubs.

In that case, I think the import library should provide entry points
for NSPR functions that are useful to application/library programmers
that are trying to use NSS, even if they're not strictly necessary.
I can think of a lot of such functions.  I will correspond with Wan-Teh
about them before proposing any additions to this list.

>> 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.

How is it more difficult to ship a shared library that offers a superset
of the LSB-defined functions?

> 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.

There are many open source QA test programs for NSS, and we often call
them "sample" programs (though I'm not sure they're very exemplary).
I was looking at the set of NSPR functions they use.  They'd be sorely
limited, I fear, if they were constrained to use only the set described
as the "bare minimum".  I will discuss this with Wan-Teh.

Regards,
/Nelson