So, for Firefox in 2017 we have a gross (meaning unrefined, broad) plan to gather the many sources of data we already have in Gecko (SPS; TraceLogger; TaskTracer; Window.performance; and on and on) into a single stream of data:
- There should be a common API to enumerate and enable/disable data sources. - The disposition of the stream can be selected: circular buffer, captured on request, like Cleopatra? Log to file as JSON? protobuf on a socket? Send to an in-browser visualization tool? - Stream entries should have enough metadata to let generic tools plot them in some helpful way, as long as they have one of the usual shapes: point in time; range of time; native stack; JS stack; textual label; id with edges to other ids; etc. We're aiming to compete with fprintf: it should be almost as easy for a dev to hack in some instrumentation, recompile, and immediately see the results in the devtools, with no devtools UI hacking required, as it would be to fprintf it and glop it up into a Python script. SpiderMonkey will depend on the stream, so it'll be present in Servo once it picks up a recent enough version. It should be feasible to have Rust APIs for contributing data to the stream, so Servo could contribute, too. I don't know what would be entailed if we wanted to incorporate the new Cleopatra UI ( https://github.com/mstange/cleopatra ) into Servo, or if that's even desirable. But I don't know of any reason it would be more difficult than incorporating any other HTML/JS - based devtool UI. On Wed, Dec 14, 2016 at 9:42 AM, Jack Moffitt <j...@metajack.im> wrote: > The only missing piece to this is the performance work / magic dom > exploration. I am already excited for next year :) > > jack. > > On Wed, Dec 14, 2016 at 10:09 AM, Patrick Walton <pwal...@mozilla.com> > wrote: > > These seem like exactly the goals I'd come up with, as an occasional > > contributor to the DOM. +1! > > > > Patrick > > > > On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews <j...@joshmatthews.net> > > wrote: > > > >> Hey everyone! It's time to make plans for 2017, so here are my thoughts > on > >> the subject. I think we should focus on the following high-level goals: > >> > >> 1) track performance metrics that are relevant to users > >> 2) address web compatibility issues, prioritized according to frequency > on > >> real websites > >> 3) reduce barriers to contributing to the DOM code > >> > >> These will allow us to make more meaningful comparisons between Servo > and > >> other production web browsers, while continuing to provide opportunities > >> for volunteer contributors to make an impact. > >> > >> Broken down, I envision the following tasks allowing us to focus our > >> efforts: > >> > >> 1) track performance metrics that are relevant to users > >> * report progressive web metrics [1] > >> > >> 2) address web compatibility issues, prioritized according to frequency > on > >> real websites > >> * implement missing/broken features required by Google Docs > >> * support the needs of the WebVR team > >> * track web compatibility issues on real websites > >> * investigate panics reported by nightly users > >> > >> 3) reduce barriers to contributing to the DOM code > >> * reduce the time required to build after changing non-WebIDL/bindings > code > >> * create high level abstractions for common patterns > >> * reduce the need for unsafe code > >> > >> We've got a good base to work from - there are still some significant > >> pieces of the web platform that we know are holding us back right now, > but > >> in general it feels like there is a long tail of smaller compatibility > >> issues that we need to address. In 2017 I want to get a handle on how > long > >> that tail is and start addressing it. This will require being deliberate > >> about trying Servo on a wide variety of sites, and filing issues to > track > >> everything that's not working correctly. > >> > >> We also have a small but enthusiastic group of people who try out > nightly > >> builds on a regular basis, and they're really helpful! Panics reported > from > >> nightly builds often go uninvestigated, and I believe this is hurting > our > >> compatibility story. > >> > >> Finally, we're all aware that working in the script crate can be a > >> frustrating experience. It's time to start dealing with the burden of > >> technical debt - we need to look for ways to write better async code, > less > >> unsafe code, and address the ever-growing, monolithic script crate. I > have > >> ideas I want to try for each of these problems, and I encourage > everyone to > >> be ambitious about them. > >> > >> I'm going to stop here rather than breaking down those tasks any > further. > >> I've got a list of issues that I want to tackle that address each of > them, > >> and it's going to get much larger once I get results back from the Blink > >> team about DOM API use on the top 100,000 sites. I would welcome any > >> feedback people have about these plans I've described so far! > >> > >> Cheers, > >> Josh > >> > >> > >> [1] https://groups.google.com/forum/#!topic/mozilla.dev. > servo/LSWE3MdUGY4 > >> _______________________________________________ > >> 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 > _______________________________________________ > 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
