On 10/10/13 2:36 AM, Zack Weinberg wrote:
On 2013-10-09 12:01 PM, Gervase Markham wrote:
In the spirit of learning from this, what's next on the chopping block?
In between "keep the C++ implementation" and "scrap entirely" is
"reimplement in JS", and I think that should be seriously considered for
things like XSLT where there's no question but what it increases our
attack surface, but there is also a strong (if small) constituency.
Where it is currently impossible to do something in JS, that points at a
weakness in the platform - whether capabilities or just speed.
In that vein, I think we should take a hard look at the image decoders.
Not only is that a significant chunk of attack surface, it is a place
where it's hard to innovate; image format after image format has died on
the vine because it wasn't *enough* of an improvement to justify the
additional glob of compiled code. Web-deliverable JS image decoders
could open that up.
The other thing that comes to mind is, if Web Components lives up to its
promise, perhaps it could be used for the built-in form controls? That's
also a big pile of hair, and form elements in odd places have been an
ongoing source of crasher bugs.
zw
I agree with the sentiment, but not on the eample.
Having been a peer of the XSLT module back in the days, we started with
a rather js DOM like implementation, and moved over to a pure nsIContent
etc impl, and each step there won us an order of magnitude in perf.
I don't think that XSLT is a good candidate for implementing it in JS.
Axel
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
