I have a proposal for the next evolution of zero-copy strings in html5ever:
https://github.com/kmcallister/tendril
This would contribute towards a number of goals including document.write,
non-UTF-8 content (~15% of the Web), reducing memory usage, and perhaps
speeding up text shaping / painting.
Let me know if you have thoughts or questions. Opening a ticket on GitHub
may be the best way.
----
I'd also like to work on security next quarter. We have some known
vulnerabilities that we need to close before we can start dogfooding or
ship a tech demo. I'll also work with Patrick to land multiprocess
sandboxing. And I have some experimental ideas for sandboxing [1][2] that
I'll continue working on.
We need a lot of people to spend a lot of time poking holes in Servo,
before we can claim it's secure in practice. I'd like to get the ball
rolling in Q2. We need to document the scope of issues that we're
interested in, and the ones we already know about. Then we need to get
people interested. I'm thinking about organizing some weekend-long security
bug finding events with small prizes.
keegan
[1] https://github.com/kmcallister/pngbox
[2] https://github.com/servo/servo/issues/3789 "high-security mode"
There are also some relevant notes from past workweeks:
https://github.com/servo/servo/wiki/Workweek-security
https://github.com/servo/servo/wiki/Workweek-dogfooding
https://github.com/servo/servo/wiki/Workweek-string-interning#dom-string-representation
On Wed, Mar 18, 2015 at 12:08 PM, James Graham <ja...@hoppipolla.co.uk>
wrote:
> On 18/03/15 17:32, Lars Bergstrom wrote:
> > Here are some ideas we've been talking about on my team:
> >
> > - Figure out CSS WG reftest integration. Right now, there's a
> > python/mercurial build process that turns XHTML files into HTML to
> > run them and it's not clear how to either integrate that without a
> > giant mess (even by servo build standards!) or upstream work we do.
> > I'd like to sort this out so we can have a test experience for layout
> > tests that's similar to that of the DOM / WPT tests, especially for
> > E-Easy bugs.
>
> I think I have a concrete plan for this which isn't too complex. The
> first step would be to put wpt (and CSS tests) in-tree directly in the
> same way that Gecko does. Then the infrastructure for updating the
> in-tree copy would be extended to also build the CSS tests. This might
> be more messy than we would ideally like, but the complexity would be
> contained to updates rather than imposed on all end users. Everything
> could be run with wptrunner.
>
> I can discuss whether this is something that I can work on, but if not
> it's certainly something I can help with.
>
> > - Critical features blocking many pages Need that flexbox. There were
> > some scheduling snafus with it this quarter, but I think we need to
> > be working on it in Q2 just to be able to build or view more pages,
> > even if much of the team is working on perf/bugfixing. html5ever is
> > going to need document.write for many pages to work.
>
> I support working on document.write as early as possible; it adds a
> surprising amount of complexity due to having non-trivial interactions
> with the parser, script scheduling and document history.
> _______________________________________________
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
