On 1/18/2012 1:30 AM, Brian Smith wrote:
they live in, and/or we may change the DLL we export those symbols from. This
will be a very positive footprint win, because it means that the linker will be
able to throw away the code for a lot of functions in NSPR and (especially) NSS
that are unused by Firefox (or Thunderbird, for Thunderbird builds). The
footprint win, combined with fewer codepaths to consider during link-time
optimization, and the knowledge that there are no unknown callers of these
functions, will likely be a pretty positive startup time win and a small
general perf win within PSM/NSS in Gecko.
I have no particular opinion about whether this is a good idea for NSS.
I do think that we should not do this for NSPR unless we decide to
remove support for binary XPCOM components in Firefox (per the ongoing
discussion in dev.planning). Many of our XPCOM code patterns
assume/require use of NSPR, and I don't think it's the right time to try
changing that.
3. Help out with the DOMCrypt effort that ddahl is leading, which will create a
W3C-standardized Javascript API for cryptography for *web* applications. I
suspect it would be non-trivial, but possible, to expose the DOMCrypt API to
extensions. I suspect that this would replace APIs from #1 and #2 above.
I tend to think that extensions would get this basically "for free"
because they have access to the DOM.
--BDS
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
