- Where: zoom.us
- When: March 13, 2019 at 3pm-4pm UTC ( March 13, 2019 8am-9am PT )
- Location: on calendar invite to registered attendees
- Contact:
- Name: Ben Smith
- Email: [email protected]
If you are a Working Group member no registration is required.
If you are a Community Group member who would like to observe, please register here: https://goo.gl/forms/HD2kLCM0iSKk7AVl1
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (chair to volunteer).
- Adoption of the agenda
- Proposals and discussions
- Future meetings
- Confirm next meeting date + time.
- Closure
None.
None.
BS: I wanted to talk about TPAC in Fukuoka, Japan this September. They sent out a survey that we need to fill out ... basically who we want to meet with and what days we want to have a room booked for us. In the past we did a CG and WG meeting... we did that last year. I think that was OK, although I do understand that made it difficult for us to meet with other groups. Because we had taken so much time there. I remember from a previous CG meeting that some people were thinking they wouldn't go to this meeting. Partially because there is a fee, and partially because we have another CG meeting in A coruna in June so there's not a lot of time between those two. So a as a result I think we might want to go back to what we did two years ago, and have our TPAC meeting be mostly about communicating with other groups. And to that end, I got an email from the WebML community group char saying that they would like to make sure that we don't overlap because they were interested in coming to our meetings. So I told the char that we would, maybe not have much of a meeting there, but we were interested in doing some outreach, and they'd be interested in talking to us about stuff too.
Anyway that's kind of the basics here. Any thoughts about any of what I discussed?
LW: I think the point about making it intergroup collaboration is a good one, and in particular interactions between webidl bindings, Domenic's import maps... I just posted built-in modules reflecting existing web APIs, which was part of the magic triad. And discussing that whole story, getting anyone who cares about that, and talking through various cases. That seems like, that would be a timely discussion topic.
BS: I agree. Especially with more of our work this year being about better interop with the rest of the web platform, it seems like that would be good. So, I guess we need to decide, how many days we need for our group. I'm thinking maybe just one. When I talked to the WebML chair, they said they would prefer if we did it on Thursday or Friday, because they are narrowed down to Tuesday or Friday, and they have a preference for Tuesday. So, I think it's likely that any day is as good as any other for us at this point, so perhaps we should pick randomly and go with that. Any thoughts?
LW: Thursday seems as good as any. Is there already a list of major groups and which days they're doing stuff. I forget the name, but the one that does Web Apps? I wanted to go to some of their things last time.
BS: I don't see a listing. It's probably because the survey isn't due until the 12th. But if there are groups that we're interested in coordinating with, the survey does allow us to choose which groups we don't want to overlap with or at least try not to. There's a large list that we can choose from: Web Application security, Web Authentication, Web Fonts, Web of things, Web Payments, Web Performance, Web Platform...
LW: I think maybe it's that web platform... is that the one that does all the storage, and streams...?
BS: I would assume so? It doesn't look like any of the... my guess is that that's probably Web Platform, and I can add that to the list so we don't get double-booked with them.
LW: Is WebGPU there also?
BS: It's interesting, I was looking for that too, I don't see that so... I don't know what that gets looped under.
LW: It was there in the past years.
BS: They were definitely there last years.
LW: I think WebGPU, WebML, and WebPlatform are the three.
BS: I'm going to go through the survey items, to see if there's anything else we want to bring up. We discussed number of days, one is probably fine. We discussed day preference Thursday or Friday is fine. Flexibility, yes we're flexible. Joint meetings, we discussed... oh this is if you want to combine with another group, we don't want to do that. Overlap, group confidentiality, we're not concerned about that. And that seems to be it. And the only other question is how many people we expect to attend. And it's hard to predict, but I imagine it will be a lighter crew. Is there anyone in this meeting know if they or other people will go to this meeting in Japan?
LW: I might be the only mozillian.
BS: Arun says he's not planning to. I imagine that will be the same here, it's a pretty big trip for just interfacing with other groups, depending on where you live. OK, well that's all I wanted to discuss today. I'll fill out the survey with best guesses for attendence, and fill out the rest of the information. Anything else on this topic?
LW: I saw you released a working draft earlier today...?
BS: Yeah, honestly I was going through and doing some of the work for the v1 CR, and one of those things was to create a v1 branch, so I created a branch called wg_v1 for the spec repo the idea is that it will be a good starting point. If there's anything we want to pull in we can cherry-pick, but we might as well have that going. And then I noticed that the releases for spec ... Brad actually made a release for the first public working draft, so I figured we may as well do the same thing for our previous working draft the one that released in August of last year. So I marked that up. Eric and I have plans to... I was expecting that he might come... we have plans to finalize the last few details of going for CR and push that out. I know that some people in w3 are eager for us to do that.
LW: Out of curiosity, is that because it's generally a good thing or is there any particular reason that... [BS: that they're pushing for it?] yeah, is it just healthy pressure to finish?
BS: I think healthy pressure is definitely a big part of it, when we met last time PLH was saying that some groups have been very slow to go through the process. As soon as you go through the process everything gets secured around the patents. That's the biggest thing -- also it's just nice to put a bow on it, and say we're done now. Another nice thing for us, now that we've branched of to v1, we theoritically could start to move proposals that are standardized. [LW: right, mutable globals, non-trapping] Yeah so we have to decide whether or not we consider those to be standardized, but that means that we could stop trying to maintain those repos and move them in. That would be really nice.
LW: Sure. Show our post-MVP incremental progress.
BS: Those are some of the various good reasons. This reminds me of something that I was looking into yesterday. Sort of related, one of the things that's helpful for the CR is to show multiple implementations that pass the test suite. A nice place to do that is wpt.fyi, the web platform test website. It has a nice display of browser along one axis, and test suite along the other axis, with colors that represent the passing tests. It's easy to drill down to look and see who's passing the tests. Currently we have, thanks to a lot of good work from ms2ger, the JS-api and web-api tests duplicated in WPT. What we do not have there are the core tests, and that was one thing that we thought might be valuable to add to that list of tests. Currently there's not another place where it is easy to see the current status... we assume that those are the tests that people would pass, but it's better to have confirmation.
I started to make a patch, but I ran into some issues ... it comes down to the Chrome 4k limit for instantiation...
LW: You know, now that you have a tiering compiler, you can maybe just bump it to 64k. It's useful at the moment, because it's pushed everyone to instantiate streaming -- which is what they should be doing. Until there's ESM integration, and then they should do that. So, it's been useful, but that being said, it might be worth increasing it.
BS: Yeah, that's a bigger discussion. It's a good point, maybe worth bringing up to people who can make that decision. Part of what I've been trying to do, make it so we can take the wasts that we have currently, generate JS using the reference interpreter, but then also run the tests asynchronous... it's probably better to do that anyway. One of the things that's been tedious is that the we want to leave the harness mostly the same, and leave the tests mostly the same, but then run asynchronous, which is all doable, but...
LW: Taking the wast, making each statement async... I can see how that's a non-trivial job.
BS: It's tricky because the harness for WPT have some unspecified behavior with regards to how promise tests are implemented, so I spent some time hacking on that yesterday.
LW: It's great to hear that... that's been the vision for a long time, we just haven't done it.
BS: I remember, years ago at this point, discussing many many times where the tests live, what's the source of truth, where do they get duplicated, how are they run, and so on. Having them up there is probably good.
LW: It's all about what's the process for these things... anything can happen. But the process can be when a feature graduates to a certain stage, and it starts down the standards track, that's a good time to move it to WPT, because then you can say, yes this is reflected on wpt.fyi.
BS: That's a good idea -- it's much easier to see. But one problem with WPT -- how do you specify, this is behind a flag? Is there a way to do that?
LW: Not an expert, but it seems there has to be. It might be in the INI? At the point that were wanting to ship, it should be in multiple implementations so it's fine if tests fail, so as soon as it's expected to pass in at least one implementation, it seems like a fine time to merge it. It'll fail -- and when that happens we mark it as don't run, or expected fail, then that's your todo list when your a participating browser.
BS: Right, so anyway that's one thing that's helpful for the CR, but also helpful for us in general. I think I'll spend some time today getting that working. Any other thoughts?
OK, let's close. Next meeting is in May. See you all then.