Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Bradford C. Smith | BSH | |
| Jack Works | JWK | Sujitech |
| Waldemar Horwat | WH | |
| Ujjwal Sharma | USA | Igalia |
| Chip Morningstar | CM | Agoric |
| Caio Lima | CLA | Igalia |
| Josh Blaney | JPB | Apple |
| Michael Saboff | MLS | Apple |
| Philip Chimento | PFC | Igalia |
| Devin Rousso | DRO | Apple |
| Shane F. Carr | SFC | |
| Istvan Sebestyen | IS | Ecma International |
| Chengzhong Wu | CZW | Alibaba |
| Iain Ireland | IID | Mozilla |
| Frank Yung-Fong Tang | FYT | |
| Richard Gibson | RGN | OpenJS Foundation |
Presenter: Istvan Sebestyen (IS)
IS: So this is the usual report from the secretariat. So first of all, I have to apologize. It is 30 minutes after 3 o'clock in the morning here, so it is very very early in the morning. So I will give my presentation then I will go to bed and if there is anything for which you need me, then you, well, it is better to do it at the end of the session because then I would wake up according to the normal time. So this the introduction… from the TC39 Secretariat. And I go to the next point. You know what has happened lately? So these are the usual points. So list of the relevant TC39 documents. So I will just show you - you know - and the GA documents that are the relevant documents during this time since the last meeting, which was in May. So we have in the meantime, also a couple of new TC39 members. So, obviously the TC39 Management Group knows that. And, also, those who are following the github they too. So the next one is to show the numbers of the TC39 meeting participation very quickly - because the trend is the same as in the past re. the latest standards’ download and access statistics. And then the very important information that ES2021 has been approved by the June GA. ECMA-262 2021 has been approved by the Ecma general assembly. so that everything went as it was planned, so that's good. Then I report back about the results of the Ecma Recognition Award, awarded by the General Assembly to them, Then there is a longer topic which is not presented here. So, no detailed information here. I have a small summary of that but I will basically then point out to the documentation that we have, because the time that is allocated to this is much too short here, this is one of the reasons. The second reason is that it is really - that TC39 people who are interested in the subject are not that many in TC39, I think, and those who are interested subject, should rather join the general assembly discussion on that and the discussion between the GA, the Execom, but you will get here, at least some entry points to the topic. And what is the current status? And then as usual, the dates of the next TC39, the next ExeCom meeting, we have an update based on the results of the general assembly and last but not least ECMA became 60 years old and that was on June 17, and normally that we have a larger anniversary celebration at the GA with a nice dinner, etc. Etc. Of course this year we don't have anything. So they are going to try to have this social event at the next general assembly meeting in December 2021, which is planned in Switzerland in the Lake Geneva area or in the Rhone-River area. And if because of covid that's not possible yet, then they would like to postpone it to the next June but then it would be the “Ecma 61st anniversary”.
IS: So it is a pretty much very similar type of presentation, but there is really nothing new. I will try to be very fast. Okay, these are here, the latest ECMA TC39 documents that you have not seen in the list of this type of presentation yet. So, first of all, the minutes of the 83rd TC39 meeting in May. It was a virtual meeting, we have just approved that. So this is already done now. The next document one is what we always do is that we are extracting from the GitHub, all the slides, all the presentations, which were delivered to the 83rd TC39 meeting, and this is not so interesting for you who are participating actively in TC39, but it is a very important aspect for the long-term archival process that we are making here in ECMA. We are transferring the information from GitHub into archival information that can also be read e.g. after 20 years or 30 years or later. And this is really needed for Ecma as a classical standardization organization, that practically the information which we are preparing here together for the development of the different versions of ECMAScript standards and internationalization standards, etc. That such information can be searched and found also after 30, 40, 50 years, Etc. So practically “forever”. So this is a typical long-term archival functionality that we have to do as an SDO. But as I mentioned for your working purposes, this is not so interesting because TC39 has its own tools, etc. You know that we are also using now one of the tools with TCQ, but we have also the long-term archival duty that any SDO requires, and we do that together with Patrick Charollais. So this is about this document and then of course, here is the venue of this meeting, and also the meeting agenda. Again, this is important for the information of the other TCs and GA participants who are not accessing the TC39 GitHub, This is not that important for you but it is for them. So this is also what you have.
IS: Then obviously, the final draft of ECMA-262, that was important for the approval, the Ecma-402, the latest 8th version, etc. And then incoming new TC39 members. So as you know if a new member comes and then wants to participate in TC39, then according to the Ecma rules, as soon as he does the admin filling in and signing administrative forms, including the TC39 Royalty Free TG form. Then we publish those and from that point of view, for instance, in this case the Zalary GmbH. Well, this company is from Germany and they can participate immediately in the work of TC39 (except for possible formal voting). And then the next document, which is the GA document 062. So this is the Ecma evolution proposal document. This has been jointly prepared by the Ecma management and other representatives. Be more specific by Jochen Friedrich, Isabelle Valet-Harper and Partick Luthi from the Ecma side. So, these were the three people who prepared that and they shared it with the Ecma Execom just internally. But now here you (as Ecma members) see this the first time, so this is an important document. It is only listed here but not distributed here within TC39. If somebody wants to know what it is all about this Ecma proposal so now then this is the document that you should search for in the Ecma GA repository, read and try to understand.
IS: and then the next one is also important. Application of Rome Tools for SPC membership in TC39. Well, in the very last minute just before the June General Assembly we got this application from a company in the US. Therefore as an Ecma member the formal approval will be only by the December GA. However, they can work now in TC39 because they have also signed the Royalty Free TG form.
IS: And then the two documents which are very important again (071 and 072) and this goes with the package about the Ecma proposal. And they contain proposed changes to the Ecma Bylaws and Ecma Rules,, which are by its nature, of course, “very heavy” for Ecma in the Ecma bylaws and Rules, because they can significantly change Ecma. The approved new version would go to the Geneva Chamber of Commerce. But changes in the Bylaws could change Ecma’s status visa-a-vis other SDOs etc. So again, those people who are interested in that topic this is something one should study in great detail (but not here in TC39, but at home), and the discussion on those documents is not here but in the GA and ExeCom meetings.
IS: Then the next document 074 is also important. So this is about the minutes of the Ecma General Assembly in June 2021. And then here you can see in great detail about details of the minutes. You can read in 8.2.1 the discussion about this new Ecma proposal. Again this is an important document, but we are going to touch briefly here in TC39 under a different agenda point later. There will be a separate Execom meeting to discuss this planned project on the 21st of July 2021. So actually, it is just in one week's time. So there will be another possibility for each and every GA member to ask further questions but it is also possible for us at TC39 as a body to ask questions that TC39 may have about this proposal,, what is it, what will be the consequences Etc? How it will work, etc. So we have basically if we want to do it and I suggest that we do it, that we should collect questions in TC39 (I would say until the end of this week) and then we can submit those questions to the ExeCom and there they should be picked and discuss it in the 21st of July meeting.
IS: Well, life goes on... we have received for TC39 participation a new Ecma application by the University of Bergen for NFP membership. Several Norwegian universities are strong actually in anything whatever they do. So I am always happy when I see that a Norwegian university wants to become active also in TC39. if I remember correctly, they come in, with the help of Yulia, and they have filled in everything. Well, the TC39 management knows about them. They are most welcome. I don't know if somebody is here already in this meeting because they are European too, i.e. in Norway now it is three o’ clock in the morning.
IS: So this is now our summary of the new TC39 members. I already mentioned it here, there were a couple of members who were approved formally as ECMA members in the June 21st meeting. So the first one is from China, Beijing Bytedance Network Technology as Associate Member.. They have already participated in TC39 meetings if I remember correctly. They are also very welcome, not just as TC39 members, but now as formal ECMA members too, The same goes also to the people from the Zalari Gmbh as SPC members. They have also done administrative work. Then for Rome Tools the same - as the last one. So these are also formal ECMA GA members now.
IS: TC39 meeting participation. Well, here you can see the list of the recent TC39 meeting participation starting two years ago. So from July 19, in Redmond, one can see 60 people participated total locally, 30 remote participants in the meeting in Redmond and 24 companies. Now, I'm not going to go through all the other meetings. Well, I go to the next slide, which lists the last meeting. It was a remote meeting. In total we had 74 participants, 0 locally because it was remote, of course. The number of companies was 27. So both the number of meeting participation, and then also the number of company participation - this includes also, by way, the Ecma Secretariat's Etc - the new companies, it is about the same. So the absolute record so far in the first slide - basically before the approval of the 2021 specification. In the January 2021 remote meeting, 95 participants, and also 27 companies, so not more than that now. I'm extremely proud of it because this represents a significant part of the entire Ecma work. According to my judgment, at least 60% of all Ecma work goes only to the account of TC39. But also the other open source projects are doing rather well. So TC53 has approved its first standards at the GA meeting. Congratulations also to them. They are also doing very well. And also TC 49, other programming languages C sharp, CLI, etc. TC49 presents their stuff over Github too,
IS: So now the downloads of the ECMA standards So these are not TC39 standards only, what I have shown you in earlier meetings. Now, since Isabelle Walch - who is in our secretariat doing these statistics and she helps me out with the figures - is on vacation, therefore I have taken the download statistics from the last GA meeting. So these are originally for those who are following the GA meeting download figures for all the Ecma standards. Now, the “red” ones are coming from TC39 and here are the “blue” ones which is the next to larger downloads of the Ecma. This is the figure of the OOXML (open xml document) Ecma standard. So that's an old standard from 2008 Etc. Then the “green” ones. This is the CLI and C# standard by TC49. And the “black” ones, which are for all the different “rest” other Ecma standards. But here for us, the message is that TC39 is extremely in the top. All together, thirty-two thousand downloads of Ecma standards were carried out during almost the first half of 2021. Now, this is the more important part for us. And this is with the status of the end of May. So, these are the access statistics regarding the HTML version of the different ECMA-262 editions. So you can see they are almost 200,000, and this one is for the ECMA-402 for the internationalisation standard. So it is almost 10,000. This figure you already know as the figures that I have presented at the May meeting are very close to this. And here - download of the Ecma Technical Reports - the Ecma TR/104, Ecmascript, Test Suite, second edition. The figure is only 87, which is very, very low and you will be wondering why is it so low…. Because this is sort of “cheating”, this TR/104 contains only the “readme file” of Test Suite. And actually the entire 30k+ small tests programs, that people are downloading or accessing those are separate (outside of this TR). They are not really included into this document, because they are added without a full TC39 approval as they become available - usually after donation by the authors. The two-page document contains only a link to the repository of the 35,000 test modules. Well this is a special TC39 product.
IS: I will go back to the most important results. Congratulations, everything was formally approved by the Ecma GA #121 and it went without any problems. Also the work of the preparation, like document publication Etc. And without problems “start” and “ending” of the “opt-out” period to satisfy the royalty-free, the patent policy requirements, according to those special rules. Well, no “opt-out” remarks were submitted by anybody. So this is exactly like in the past 10 years. Etc, no change on that. But so it went through. So we have passed that Etc. And then Documentation which you can see is the relevant documentation, the announcement of the opt-out period And then here these were the official drafts. Presentation, publication TC39 depository, Etc. So we have done that two months before the GA meeting, also exactly according to the WTO TBT rules, how this is how it should be, so that was done and congratulations again.
IS: Now the Ecma Recognition Awards. I have already reported to you in May that unfortunately, from our proposal to the ExeCom / GA, not everybody came through, but okay, let me start with a good news. So I would like to congratulate Jordan Harband. He is one of the oldest active co-workers in TC39. And he's also the “champion” for bringing in several new Ecma member companies as he changed his companies and so he has been real sweet a, if I remember at Airbnb. Etc, etc. So here's his present new member company, Coinbase.. So I would like to recognize Jordan’s excellent activities for TC39 and this has been also reflected so by the General Assembly. So so let's go to the next one. [applause]
IS: Next Meeting Schedule: The next few meetings are remote as Aki has already announced, in alternation between 4-days and 2-days long meetings until the end of the year. No change this year. But we have to continue the discussion about what the next year schedule should look like. According to the first presentation, maybe we are going back to the to the 6 meeting plan. I'm sure this is a separate discussion again, so I'm not going to touch it. But we need sooner or later, or rather sooner, the schedule for 2022.
IS: Then the next meeting is the official one. It will be 8th and 9th of December 2021, so it will be either the first face-to-face meeting, or it will be still remote. It is not decided yet. It is also not decided whether it's going to be in Geneva. Geneva in December, it is not too nice. If it will be in Montreux, Montreux is much nicer - with a nice Xmas market - and this is just one hour with a train from the Geneva airport. Then in Crans-Montana, which is listed too. This is up into the mountains. It is in the Rhone Valley so that's about two hours or maybe three hours with the train from the Geneva airport, while passing the Lake Geneva area. Nice trip. And then go into the Rhone Valley and then it will be on the left side that's a village one thousand, three or four 1400 meters high up. So this is a snow resort Mountain and it is usually very good skiing early December, you would already have snow. If it will be a remote meeting then the Summer meeting will be face-to-face in the Geneva-lake area. One word about the ECMA 60th anniversary, which will be celebrated in the first face-to-face GA meeting depending if that will be in December 2021 or in June 2022.
Presenter: Kevin Gibbons (KG)
KG: We've made a few non-trivial editorial changes. One update that you might notice is that the equality operations were these sort of abstract-operation-like things that had their own calling convention and syntax and that was weird. Now they are just regular abstract operations and they have been renamed to make them clearer when using the regular spec internal calling syntax. So that's 2378.
KG: 2413 is, I rewrote all of the machinery for async generators because I have looked at it several times and been confused by it every single time I have looked at it, there is at its base, a relatively simple state machine, but the state machine was all routed through this message pump that did not make it at all clear what was going on. I have re-written it into a much simpler, not recursive state machine, that just does the transitions and actions. Hopefully that is clear, but if you are wondering why your implementation comments that have the specs steps don't match up to what is currently in the specification, it's because of this change. I think it was worth it on balance to make the machinery clearer.
KG: And then this last item is, we introduced a mechanism for defining spec-internal closures a while ago. We also introduced, a few months ago, a mechanism to use those closures to create built-in functions, rather than the prevailing style, which was to have a separate clause that listed all of the steps and coordinate state via internal slots. Now we can use abstract closures inline, which is much more concise and I think easier to follow and we have done that in the places that it made sense to do. This is incidentally, it's closed one of the older issues on the spec because this has been something we wanted to do, or other consumers of the spec wanted to do for a long time.
KG: Also a few meta changes. So this first one: as you are hopefully aware, we have a multi-page build of the spec, which is useful primarily to people on Chrome because Chrome chokes on large pages. Now I've added a shortcut to toggle between the single and multi page version. You can just press m and it will bring you to the corresponding section on the other version of the page. And then the second one was a contribution from ms2ger (thank you ms2ger), to make it so that when you click on multiple variables they highlight in different colors. There is a screenshot. So you can see rather than all of the things being highlighted with the same color, the different variables have different colors. That's why there's different colors now if you're confused, it’s because there's different variables. I love this contribution.
KG: And then the next thing, which hopefully you shouldn't notice, is that we have migrated from Travis to GitHub Actions, because as if you do any open source work I am sure you are aware, Travis has basically kicked everyone off. So if you notice builds not working or something, this is what's going on, please ping the editor group, and/or Jordan and we'll try to get things working again.
KG: And then, this last one, number 545, I have brought up at each of the last dozen or so meetings. We are still in the process of changing the headers for abstract operations. We almost landed this today but it's going to be another couple of days. Again, this will only affect the authoring of the document and not its rendering.
KG: And then normative changes, there's only one that has landed since the last meeting. We got consensus for this at the last meeting to make the shared array buffer constructor's sole parameter required instead of optional, which affects the length property. This was already web reality. And then we, again almost but not quite, landed the change to move the __proto__ accessor and object literal syntax out of annex B with the accessor being marked legacy. This hasn't quite landed yet but we have done the infrastructure changes necessary to make it happen. So it will probably happen very shortly.
KG: And then a similar list of upcoming stuff, which, I'm not going to talk about all of these in detail because we have talked about all of them before. We haven't added any new ones except this last one, which is, now that we have or almost have a syntax for structured data about abstract operations, we want to introduce new data. And one example of the data we want to introduce is whether a given abstract operation can in general or at any particular call site invoke user code, which is something that is extremely useful if you are an implementation to know whether this is something you have to worry about potentially having arbitrary side effects or if this is strictly internal. So, hopefully someday in the relatively near future will come with annotations that tell you that. And that's it.
MM: You mentioned the __proto__ accessor being marked legacy. Is that also normative optional and his legacy employment of optional optional. I don't remember what we agreed the marking of Legacy means
KG: Legacy does not imply normative optional but in this case I believe this was also marked as normative optional.
MM: Okay, and the syntax is neither normative optional nor legacy, correct?
KG: Let me confirm that very quickly - the syntax is neither normative optional or Legacy that is correct.
MM: Okay, thank you.
KG: Sorry, I should have mentioned this. This PR also includes the definegetter and definesetter accessors, and the lookup versions, which are also Legacy and normative optional. Just like the dunder proto accessor.
JH: To clarify, something can have Legacy or normative optional or both or neither. So like we can decide what what fits each thing,
Presenter: Ujjwal Sharma (USA)
USA: So hello. I'm Ujjwal and this is the Ecma 402 status update for the Japan meeting which looks awfully like my home these days. So what is Ecma 402 for the uninitiated ECMA 402 is a specification that contains an API JavaScript built internationalization Library, so let's say you have a date specifically this date, you can convert that English us and get the interesting u.s. format or the British format or the Japanese format, which is so much more efficient, why don't we use that?
USA: So how is Emma 402 developed? Ecma 402 is as I just mentioned a separate specification for many and it is developed by another subgroup of the group we're in right now is TC39 TG1. That specification is developed specifically by TC39, TG2. Proposals a for a team approach to move through the standard TC39 process we have monthly calls to discuss details and if you want to join and if you're interested, shoot an email at this email and there's more information at the Repository.
USA: So just to go through the normative pull requests or in this case, normative request, There's only one. There's a pull request by Frank and actually I can just go through the text on this one because it's so small, but it's a normative pull request which says, add lower case mapping. So this one is the case, sensitivity in case mapping options. Sorry. Instructions. And this includes mapping for lower case to uppercase abut just doesn't Define the other way around. So this adds text that says, first of all, that no other characters are mapped. So none of the non alphabets are mapped to anything else. And then it also specifies what to do with the upper case. so that's just how things work. So it's not changing web reality. It's just improving the amount of specification we did. So that's this. It's highly uncontroversial. We have multiple positive reviews and this was pointed out by Andre. So thank you Andre, while reviewing. So just to stop for a minute, do we have Consensus on this one?
AKI: Seems like yes.
USA: Okay. Perfect. Thank you. Just going through the different stage three proposals. We have right now. We have quite a few. First off we have everyone's favorite: intl segmenter. So Intl Segmenter, this is championed by Richard. It's it's one of the old ones, it's shipping in V8 and JSC, it's pending in spider monkey. But some cool things are happening and there's tests for this one. This is how intl segmenter works. You can. you can put in your favorite Locale and what kind of granularity you want: sentences or words? This case we have word then you can segment over a sentence. So it gives me "hello" and "world" which are two words.
USA: So yeah, intl locale info is next. This is championed by Frank. And if you run V8 in the harmony mode, this is already implemented. It's not shipping though, so it's behind the flag and JSC and then spider monkey still implementing this. This one gives you additional information on the intl locale object. So if I create an intl locale object with locale Japanese it gives me the calendars is Gregory which stands for the Gregorian, calendar and Japanese. And then this relations for the Japanese Locale, there's hour cycles and so on. And if I go with English US, the set is different and has tons of timezones, so many hundreds of timezones, which I guess is good for Japan that they only have one time zone.
USA: Yeah, so next up, we have Intl display names V2. So this improves the existing Intl display names object. This is also championed by Frank and this is implemented in V8 Harmony again also in Spidermonkey nightly so 91 to be more precise. JSC is still pending. And for this one we need tests, so if you like writing tests in JavaScript, feel free to help us, that would be really appreciated. So, this one's quite interesting and straightforward. You can create a display names object using whatever locale you like. So let's say I want to see what the names of different calendars are in English. there is the RC coming And I can do that. calendar (?). So on and I can find the names of all these calendars in Japanese as well. So that's been helping me, learn the language.:A
USA: And next up, we have extended time zone name. So there is a time zone name, option, in date-time format in this proposal and this expands that option to accept values. This is also written by Frank. Thank you Frank for championing so much stuff. And this is also implemented in V8 Harmony and in spider monkey and JSC is pending, So implementing tests are also wanted for one. And if you see my time zone in English - or actually not my time zone but Pacific time, so maybe your zone - this is all the different ways you can now Express the time Club, so you got Pacific Standard Time, Pacific Time, PTPT, everything, and then, you can also do that in, say, Japanese.
USA: Regarding stage two and one proposals. There's Intl duration format that is stage two and I'm the . It's not for stage advancement this time unfortunately, but hopefully next one. There's Intl number format, we stage 2, and championed by Shane, and it's going for stage advancement, this meeting. So keep an eye for that. There's internationalisation enumeration API by Frank. Also going for advancement, and then there's a bunch of really interesting stage one proposals that we're still working through and they're not going for stage advancement this time.
USA: If you like this and if you like the general idea that we're working on, how do you get involved? Well, as I mentioned, here is the repo TC39/ecma402. So feel free to drop by part of an issue. You can also give us feedback on open issues. You can help us, right? MDN documentation, We have a specific repo ecma402-mdn, track and follow progress on MDN stuff and you can implement the different proposals that we talked about in JS Engines and polyfills, you can also help us write tests 262 test and add the plumbing to ICU, which is a native library that enables browsers to do most of these interesting things. To join our monthly calls, email, we’d be glad to have you. And thank you arigato.
WH: I'm curious where the “h23” vs “h24” hourCycle nomenclature came from. The intuitive thing would be to write “h24” for a 24-hour clock but that's almost always wrong.
USA: Yeah, I believe the hour cycle preferences come from the Locale itself. So each Locale has a default hour cycle that is sort of preferred for it. So for example, English us would have “h12” if I'm correct but many others would have “h24” for example
WH: Actually, I think anything which uses “h24” is probably wrong. What you want is “h23”. I’m curious where these confusing names came from.
USA: yeah, I think the list of hour cycles by Unicode also follows this convention so maybe that's one of the places where they drew inspiration from, but I think Shane or somebody else from TG2 might be able to answer that better. I can raise this later offline.
AKI: Thank you.
Presenter: Chip Morningstar (CM)
CM: ECMA 404 The standard rests unchanging As we meet again
AKI: Thank you very much.
JHD: I don't think there's any updates at this time.
GRS: Hey, everyone, I just do a quick introduction because I haven't had the opportunity to meet everyone yet. So I'm Granville Schmidt. I work at F5 in the office of the CTO where I work on Innovations in the future of applications, and I have a background in security, application development, and startups. And I have spent a lot of time in open source across different technologies and languages. And for me what's really exciting about this opportunity is that in security everything's built on different layers and they all build upon themselves and one of the most foundational and critical layers is the underlying language, right? And JS is a language which is used by many applications. So getting the opportunity to work with each of you to ensure that one of the most critical layers has many eyes on and we review it and we tackle security issues early on It's really exciting to me. So thank you.
AKI: Do we have consensus for Granville to be chair?
AKI: I think that is consensus. We've had a lot of time thinking about this and I have heard positive yeses in addition to the silence of agreement. Congratulations.
GRS: Awesome. Thank you so much. Look forward to working with everyone.
IS: This is IS. So the first one will be, you know, that from Ecma Secretariat. So we will need - I will be contacting you and also the secretary From the second that Patrick's utterly in order to work out, you know, to what you did, a presentation on the Ecma website. Should be for the, for the TG 3. So this is a rather important and formal action in order that the tg3 should be also formally recognized and seen from the outside. So first of all, thank you very much for for offering your services and and congratulations and thank good luck for the work.
GRS: Thank you, I look forward to working with you.
Presenter: Istvan Sebestyen (IS)
(notes from this section are on the Reflector)
Presenter: Kevin Gibbons (KG)
KG: Okay. So the title slide here is perhaps slightly more provocative than it needs to be. Okay. So this is a normative pull request. Well, arguably normative, arguably editorial. The content of the pull request, is - you see this highlighted bit of text here? This highlighted bit of text says that Boolean, like capital B. Boolean, was designed to be subclassable. This is technically true. It was technically designed to be subclassable. I think this is a very strange thing to call out. The intended reading of that clause according to Allen is just that it may be used as the value of an extends clause and things will work as you expect, in that this will create an instance of Boolean with all the correct internal slots and so on. People read this to imply more than that. In particular, some people read this to imply that it is intended to be subclassed -- that we are actively recommending that you subclass built-ins. Of course, this is not just true of Boolean. This is true of every single constructor. We do not differentiate among them. We say Boolean is a designed subclassable, Function is designed to be subclassable (though good luck with that if you are in a CSP environment), we say Array and Map and Set are designed to be subclassable. Now arguably some of these it may make more sense to do so. But like I said, we don't differentiate among them and I think at least for Boolean, it is extremely silly to call this out. So proposal, let's remove that, specifically this highlighted part [highlighted text in slide 3]. This is not an endorsement of subclassing any particular thing, this is not expressing opposition to subclassing any particular thing. I'm not trying to say that you should or shouldn't subclass Boolean, or Map, or Array. I am just trying not to suggest that you definitely should subclass every built in which the current wording suggests to some people. If you are interested in calling out a particular subset as being a good idea to subclass you're welcome to do so, as a separate effort.
KG: I guess I should review the history before I ask for consensus. This came up in the context of Temporal where the operations in Temporal do not defer to Symbol.species because they are sort of a bag of classes and it doesn't really make sense to try to subclass one of them and assume you automatically get the “right” behavior because you will get nonsense, if you convert to a different type and convert back, and so Temporal does not provide particular affordances for subclassing. And so Temporal wanted to remove this wording for their constructors. I think this wording should be removed from every constructor. We can just leave “may be used as the value of an extends clause of a class definition”, which is a plain statement of fact. Can we have consensus for removing this clause?
JHD: My initial, the tldr here is I think removing this is a strict Improvement because its presence does signal to many people that you should go ahead and subclass these things with, you know, with class extends and go nuts. The follow-on change I would like to see and that if I have the time I will pursue but I'd love to get thoughts from folks in the committee on like, do we even know what subclassable means? Like the species removal proposal defines, like four types of subclassing. The Set methods proposal has been stuck like in which ways should something be subclasible like in which types of things should be easier than others and things like that. So I think that removal is good. I would love to see us as a community agree on what subclassing means and somehow Define it and then notate which built-in Constructors are reasonable to extend versus, which are simply, like, possible to extend. Because I agree extends Boolean is silly. There's no use case for it, but extends Map has use cases, for example. So I want to put that out there, but either way I support this change, because it's an incremental Improvement.
SYG: Yes, strong support for this. Largely aligned with - well, completely aligned with Kevin here. Maybe a little bit different for where I want the editorial direction to go from Jordan which is I think we probably don't want to - Like I want to say the strictly true thing in the spec without additional qualification, without saying things like “reasonable” and “designed to be” at all. But for now I think this is completely the correct starting point, is to say exactly the thing that is supported, which is, it is supported in the extends clause. So 100% support.
JHD: Whether it's actually in the spec or not, I still think it is incredibly important as a committee for us to decide what the content of that sentence would be even if we don't put it in the spec, right? Like, because it has informed many current proposals and possibly future decisions.
SYG: Yes, completely agree.
MM: I just want to clarify, is there anything, in terms of the criteria of what this phrase means, is there anything currently in the spec that is not extendable or subclassable? That - I take it by the criteria here - that is not something that one could meaningfully put in an extends clause?
KG: So this wording is used specifically on constructors. You can't put something which is not a constructor in an extends clause. Other than that, no.
MM: And by constructor we just mean anything with a construct Behavior.
KG: Anything with construct behavior which isn't throw TypeError, yes.
MM: Okay yeah. I mean I agree. I completely support the goals of this PR.
KG: Allen clarifies in the thread that the reason this was added was because this was not necessarily true in es5, you would not necessarily get the correct behavior - meaning all of the internal slots setup and so on - which is why this wording was added in es6.
MM: Well, in es5 there was no extends mechanism.
KG: Yeah. If you just set up the prototype you would not have the internal slots and ES6 gave us a way to have syntax to set up the internal slots.
MM: Okay. Yeah. I support this.
Aki: All right, the queue is empty.
KG: Okay, consensus on this pull request then.
Consensus for tc39#2360.
Presenter: Frank Yung-Fong Tang (FYT)
FYT: Hi everyone, is Frank Tang and I'm going to talk about 4 proposals today. Tthe first three are just 10 minutes slots for three of the stage three proposed. So and I just want to keep update to everyone. So you know what's going on right now. And the fourth one, I have a 30-minute slots us for stage three advancement.
FYT: The first one I'll talk about is the Intl local info API in state 3. So this not for any stage advancement, it is just to give you Update. So the base motivation is for a proposal to expose a Locale info such as a week data, including the first day in the week, weekend start day and end day and first day in week. Hour cycle used to be in the Locale and the measurement system using Locale that part actually got remove doing that. This is all original charter, but we removed that.
System part in. it was advanced in to Stage 1 in September ofl last year in stage 2, in January and stage 3 in April year. They are some changes and discussion during their(?). And one of them are like to ask you for a consensus. There are being Torre talking the TG2 Institute, get Intl Locale property collations, which is supposed to return an array of all the collations that are use in the Locale? And we do not have the language to exclus all any of them, but I think Andreas from Mozilla point out that because in the collation API clearly stated that collation for option for standards in search should be excluded in that API because there's a different way to invoke it not food localization option, but through usage option. therefore, He suggested that we remove it and just adding say, hey this thing shouldn't be returned there. So later I would like to ask you for consensus for it. In the June, tg2 meeting date, another member to look at it. Think that is the right thing to do. There are also there are some additional thing during the say three that bring up by Andreas and he did a very awesome. Review and that we may need to still do additional changes. Most, some of them are editorial. Some of them are just clarification. Including I think we didn't sound how clarify in the appendix. A about Vision, dependent Behavior with the new additional API were added. Something should added to the appendix. We somehow forgot to do that. So we need to add that. The other is there is some suggestion that we should clarify that. of Locale on the items in their array, that quick but got returned from that. So it was discussed at all. whether that order has a particular meaning or, or So, the current spec says that should be in the prefered order. I think Andreas pointed out the first one that for sure, is the preferred one. But the rest of them may not be. so, that is still under discussion and I will bring that to TG2 and to you later on if we believe there are some agreeable, action. The other thing is, we will try to ask for clarification for whether the (?), the calendar Locale extension. will have impact two-week info or not is still under discussion about that. and also, there's another one's asking for, Make it clear, whether that return IDR canonicalize, I think when I wrote it, I was assuming everything gets returned will be canonicalized by think that requires us to make it clear. It is a canonicalized before said before return, which I think is a good point but I somehow just missed that. That neither one is very interesting that we sell her. Our API didn't account for a condition that I not aware of before stage 3. Some of the part of the world? I think in that in some style other region, not a country. But some like a part of the stable part of the province, inside a particular country are using a non-continuous weekend. So they have probably be even half of the Christian and Muslim population. So they actually choose to have weekend on Friday and Sunday, but not Saturday. And that is somehow not very presentable in our current model. So we are still trying to address that. We are trying to figure out how to address that we don't have a conclusion yet. Unfortunately, the it was not bring up before stage 3 so we still need to look at that.
FYT: And then we have two editorial requests and I think so you can Take a look at of that. There are more editorial issues. So, in the implementation currently will have pulled out coming, we have an invitation for Chrome and not to with under the flag is not flip yet. We are animals up in Chrome or shooting. Maybe we can flip it by end of Q3 and there's a status check. You can look at it, we are currently in Chrome is pending on more complete coverage of the test. USA has contributed a lot. I think we still need to take a look and see whether others are any missing issue. I think Mozilla has also on the development and really quickly working on that, but I see his blocked by solve the issue I mentioned earlier. He's asking for clarification and decision so we're still working on that part. It's not clear of what's the status of a safari. If anyone from Apple know that it will be nice to tell me. And we really need more help. And hopefully, we can. I think we have a, some tests in test262 but you know, more tests is definitely better. So, There's a particular flag tag in the feature flag to seek to it's using the a string. And we still need some help (?) have someone to help polyfills. So particular I would like to thank for all the people list here Shane and ZB from Mozilla did a great stage 3 review and many people, particularly Ujjwal and the many others. in the discussion that contribute to that, and particularly for Andrea who found a lot of very interesting question doing his implementation.
FYT: So I have two asks for the committee. The first is retrospective approval for the change of to exclude a standard and search found the return of that list. The other one is just basically recommend people really helping to write more tests. So, may I ask, is there any question on the queue about the update. And if not, I like to ask the approval for consensus for the first one.
USA: There's nothing on the queue. And yeah, I think you have consensus.
FYT: Thank you, I appreciate that. so, if anyone have interest to help work on the task, please let me know. otherwise, I will move to the second presentation.
- Consensus for removing “standard” and “search” from Intl.Locale.prototype.collations.
Presenter: Frank Yung-Fong Tang (FYT)
FYT: This is another proposal. Just want to give an update just already in stage 3. This is called Intl display name version 2. So which means where you have a version one in the state for while, and this proposal is kind of on top of it. The motivation is to try to enable developers to get translation of All language regions, scribbled out of this. Plain language already cover version 1 but this basically add additional one. But we also try provide straightforward API to do that because the are sometimes time, have some edges you can work around and get us anything but which may faill in certain condition. So we try to encourage to give developer to call this API instead of those worker around condition which sometime were some that don't and they causing some more problem. A little bit historical background. So let's hear about version 1 energy in stage 4 in September last year. and this particular proposal version 2 is introduced in August. Try to capture something that we somehow cannot accomplish in subversion one and it's got of answer for stage 1 in September Last year and January to stage two this year. I gave update actually, I think we're supposed to be to April, but didn't consensus that time. Have some less minutes issue but we so we postponed it. But we addressed it in advance to stay three in May already. So it feature got enhance in this particular proposals. Adding a languageDisplay option. whenever the type is language, option will accept either (?) and also adding additional type one is called calendar together, neon of the counter one is daytime feel to get a data field ningún of the particular the name for that opportunity times field. So for example just give you give you show you some feature. This is the language display. The left side is showing you asking for it. The language in the dialect mode, which is the default if you adapt to the option is removed and will be default to die. Like one is ten armed and for example Eng be in the dialect mode will show us in the area under the English locale will return British English but if the you what standard Overturn English, params, the United Kingdom in the English Locale. I probably should choose another, like a Locale language code to show that. But anyway, that's that's the case. I think can see from the example. Similarly calendar, right? This is a return the name of the calendar. For example, the Minguo calendar in English and in Chinese, it will ask for Chinese calendar (?) political calendar in for that, particular Locale. Similarly, there be this is a showing the labs is a Chinese writing Spanish, and showing you daytime Phil. So if you ask you for name in Spanish, I don't know how to pronounce that Spanish word. Etc.
FYT: So, what happened during stage three. So we are a already advanced to stage three in May, and so in Chrome it is developed in the check in, under a flag in the harmony intl display name V2 flag for Chrome and 93. So anyone on 93, I don't think is stable, it is still under beta Channel. or dev Channel, but once you get chrome 93 you can try it. I mean V8 is aiming, try to flip to shipping mode in Q3 which means still take some time. probably in queue forward to roll out to the user. We again is just a preliminary plan, we haven't gotten all the approvals yet, which do try to work out some quality issue and you can see the status page here. Mozilla has landed 91, which is - I'm not a hundred percent sure how the Mozilla work in terms of rolling, but I think that means you have an implementation, there may be other flag, you can look at a book report ID to figure out the detail. Safari. Similarly it would be nice if someone who works on that. Would tell me their status, We have test262 and have a particular flag for that too. it would be really helpful If someone can work on building adding more tasks for tests for this particular feature, that would be really appreciated and it will be appreciated to contribute to MDN and polyfills. So basically, that's what we are. There are no additional issue about this yet since we're still working on, you know, to try to have more supporting activity, just whatever I mean. Here. So also, I would like to thank Shane for his leadership and review and Ujjwall for us stage 3 reviewer for this and(?) and other members.. Thanks for India. Also in, he did sound work on Mozilla and give us some feedback, which is pretty nice. Any question about this particular proposal?
USA: the queue is empty. So I suspect not
FYT: so, my request for the committee is there, no question or whatever it, just try to help The development of test was easy to and poly fill in the end and tell everybody about this API. So other people use Maybe submit some conference talk. Anyone else?
USA: No, but thank you for the presentation.
No questions were raised.
Presenter: Frank Yung-Fong Tang (FYT)
FYT: So the third proposal already in state 3 is called extend timezone name option. So the motivation is try to in the daytime format and . We have this option of time zone name and we do try to have more control and more additional support for that. history, is that it was, it was Advanced stage the January meeting this year and in the April tg2 we renamed sorry typo here but Irene And we have discussion reinstall the original strawman proposal short GMT, long GMT the short offset and low upset and it was advanced in April meeting. And then later on in the TG2 building during, you see through discussion. We also renamed the other two options from shortWall longWall to short Generic and longGeneric and last time in a place. in May we came here and asked for stage 3 and got it so it is now stage 3. Just to update, you know, this is a new one in there (?). the highlighted one is showing you when it got display in English, what it look like. Or, you know, it display in traditional Chinese Locale. What you are look like, you know, so sometimes song Locale actually will use GMT or CEST UTC or some other string, but it will be an offset from the UTC. So again, basically, there are not much activity and in so far so good and I would like to thank these people for helping working on this proposal. So in particular, Philip and Rick my stage 3 reviewers and also Shane's leadership on this. And currently, Chrome also implemented in M93 and Mozilla in their 91 release. And again, this all currently under the flag and people play with it. And give us feedback. if there's any issue again, they're also says some need for test, 262, MDN and polyfill. and again, the same thing, you know, just request for helping on test262 and MDN and polyfills. Any question about this proposal during the stage three?
USA: The queue is still empty. I think you're super clear.
No questions were raised.
Presenter: Frank Yung-Fong Tang (FYT)
FYT: So this is a the for proposal different than the other three and asking stage 3. This is the Intl Enumeration API. In the charter for the enumeration APIs, try to list the support of value of options, in pre-exists Ecma402 API, me there are options already there, but it's not programmatically developer discoverable. We are trying to make it discoverable. One is calendar, one is Collation, one is currency, one is numbering system, one is time zone, one is unit. Within this 402 says you can support this list of unit and can only support this list of unit. Number system, say there is a table. You can support at least this numbering system but you can support more than that. the order we do not actually have a clear specification in ECMA402 Which one could be need to be in common or (?) increment or you know, whether the implementations have it or not. So what happened in the past is people will try to some way to call the Constructor and then called observe result.. And then to see whether that got resolved to the one they into, to the feature task, which is a lot of work and could be pretty hacky. so here's also a less of whatever the appendix a in Ecma 402 mentions. that some of those fields or this option are implementation dependent support, right? So, the set of the calendar are per locale, the set of a support acylation Per locale. The setup was supported. numbering system per locale and the implementation of the number system, not listed there could be supported and the pattern used for formatting (?) Could be supported per Locale and also the calendar calculation of time local timezone. How many time zones should be supported. Those are clearly stated in appendix A to be implementation-dependent. The problem is there are no problem programmatic way to figure out, you know, easily to figure out what those implementations supported. So how can we figure it out, right? One way is do currently - I think there's a polyfill. You can feature ttest one by one, it possible to do that but is not very straight forward and become very clumsy.
FYT: To give a little background, the proposal was actually originally discussed and motivated by a Temporal issue about what time zones are supported. And they said, maybe time temporal Originals they maybe should be there but they said well no this shouldn't be part of Temporal to figure out how many time zones reported so they talked to TG2 to say whether we could take care about that so teach you to discuss that and I say okay I'm going to sign up to Champion for that. Of course, in the meantime, there are some discussions that we should support other things, not just time zone. So, in last year, June last year, a year ago, it was put together and advanced stage one. In September is Advanced a true in particular time time. One of the major motivation is the Our concern about fingerprinting, but they also believe I think we also believe that unless it is advanced to stage 2 it is hard to get expert from other standards body to take a look and Give us feedback. So it got stage 2. And I think the motivations of I want to get stick to doing a stage 2. We can get more feedback and to study whether that this will expose fingerprinting issue for the user may be careful. Fingerprinting the user and fingerprinting. The browser are two different thing where particular talk about fingerprinting the user to, for their private identity concern. So, if we have an update in November last year, and during I think late last year, or maybe early this year, I think tg2 also believe we should have some new guidance because there's additional (?) guidance what kind of stage two or three proposals should be forming. in tg2, I think because we have concern about data and prior art. So they are the prior art difficult. From in the usually and brought (?) additional guidance. Things I say to of requirement inside TG2 to and also what's that called a payload size? Requirement for stage 3. So that come after this or the events TG 2. So in we retrofitted to discuss that in the March meeting and I think TG2 agreed that it is proposal fit that question all criteria for stage three. Also in April I think, Mozilla and apple both, I think Mozilla first published their conclusion about the privacy or fingerprinting user concern, and concluded and apple. I think also take a look at it and agree with their conclusion. So, in that time we declare the concern about the Privacy or fingerprinting issue closed. So we can look at issue number three as the closure for that. So in TG2 in May several member expressed their support for stage three and so I that time those the last not quite sure, So we say we're come back to us before and the May TC39 to should tell us their stand. But I think there's something - I forgot what exactly - spme concern I have with proposal. I decide to postpone it but I give an update in May and particularly may I also ask other people's people's feedback and I several feedback in the discussion and so I have the rest of this particular proposal. I go over structure. based on how I responded to stage three feedback.
FYT: so I change that whatever the feedback to three action item and we can discuss that. Oh by the way, before that, I would say and June TG2 meeting, we also talked about one of the particular issue about returning a discussion, a lot of people Expressed their opinion and have made some changes after that. And also TG2. Also, I think in the July meeting, we come through, one of the options was a ship or issue, our shorthand for that. But later on I will tell you what is the issue for that. So so here below structure. Based on that, three Three particular feedback that we receive in the meeting and hopefully, after going through that, you will see how that got addressed, I think one. The first one, by the way, this is not order by the issue Dimension during a meeting but rather how the The water I address it. So I think its first column last last came first somehow, because I saw what grass the last (?) just try to follow the line.
FYT: So first, I think action item is mentions by Mark Miller is that the returned iterator had a hidden primordial. So after discussion looking through that we agree and I think this is an issue and so the conclusion that we changed the draft. And currently, there's only one method in this API, which is called Intl supportedValueOf and before the last meeting, the value is an iterator, And there's a prototype And after discussion, we decided to change it to just return an array. Okay, to change your rate of return time to the way we believe that will address, MM's suggestion.This is also was suggested by Andreas from Mozilla, he just suggest we return an array instead of an iterator. Or because I think the largest that array we can return is of length 550 or so, it's not huge and there's not much computation there. When it returned, iterator didn't save much the lazy evaluation, this memory is already there. So we just decide to change it to return of an array instead to address that particular issue.
FYT: So, here's example, after we change it, what it look like so you will have this function call to say, hey Intl supportedValue of "calendar" and tell me in this particular system. Let's say you're only gonna know that (?) is on the server side using V8 and user requests have a HTTP requests coming say, Hey, you know, to get returning HTML, what are the calendars your server supports, right? And this, JavaScript API, and the V8 nodejs can call this API to figure out what the know that JS api supports and formatted HTML and return. And Cetera. You can do it for currency. If a number system time zone and you know, of course, you can also run this in Chrome or Mozilla once that shifted there. But you want to remind you this is not only used in client-side, but could you also used in server-side JavaScript?
FYT: So, another option we which thing with change I think is also mentioned by Andrea from Mozilla. Originally We have a option for the time zone. We say okay we can say the region is US - the idea is that originally there are an option for region US but Adrea, say, well, you already have the intl Locale API in stage 3, and this, you know, sis, this particular API do not need to have redundant work with that and agree. So, because you only need to say, hey, this a bad tell us what, what kind of time zone are supported, and the other one was that in which time zone I prefer in that particular Locale and then intersection will tell you which one will be supported in that Locale or region, right? So, we removed this particular option, which is recounting. so because, you know, sometime maybe next year maybe Marco Rubio will invent a permanent Daylight Saving Time in Florida, who knows? Maybe there are passing the u.s. So we may have new tizen who knows right. And if IANA has a new time zone ID for that, and maybe some process or adding a new one There that there are no easy way to find out unless we have an API to show that or user have to do feature test, and this is an easier way to figure out that.
FYT: the second action item I think is coming from YSV from Mozilla about shipping the entire payload, I think there's a direct quote from the meeting notes, to add a requirement that anyone who ships this ships the entire payload. I think during the meeting I was very confused about what does that really mean? So I try to address that but that's the tag. I mean the the request of time. So I try to now, so first of all, I have to have some critiques about that request. The critique is basically first, they're not real, no definition about what is all requires or for entire set or or anywhere. Right? As I mentioned earlier, the appendix a already simplified, the supported are implementation dependent, there is no definition in ecma402 to say what is "all". There is no list of all the calendar. calendar. All the Collation Etc, except unit. Therefore there is no way we can base our admin for to the say what all tries also have problem, right? Because times are not defined by Ecma262, time zones is defined by IANA and they may add additional entry, right? We never know what will happen. So you know it's not in our hand, there is no way we can say what is "all". But CLDR or UTS35, how about that Locale? Actually they do not Define. What is all because I think they are basically believe that over time support from different minority language or country will be added and by Design they try to make it an open set, right? So it's possible in the next version, there will be additional more so they don't really have - and also see how they are currently after Define something more than ECMA465, for example numbering system, Roman is defining in CLDR, but Ecma 402 it Not true should include at there in the Roman numeric style in the Ecma, for to, right? So it will (?). We cannot just say, okay, we should we require to ship all the CRT are because ECMA 402 to currency but those are not needed to be shipped if you want to ship that for now. And citizens, okay, but not for example, V8 in Chrome is not stripping that so, also the browser for practical uses of this problem. usually multiple scenarios or our practice only support subsets. The currency code now, all this their currency. Fell are historical and nobody uses anymore but they're defined nice. Alright, so some of the browser to decide things which (?) and there's no clear domination and there are different version ISO, which what is also? It's very difficult to achieve that. but anyway, I think you'll learn actually you Yulia actually later on, I think concluded - Shane asked her whether this issue could be considered as a general 302 issue not tied to this particular proposal and I think she agreed. This is general issue that could be addressed separately, I think there's a good concern about fingerprinting, but it is difficult to define what is the "entire payload". Is a very abstract concept for the reason I mentioned above. because there’s nothing we can refer to the say, what is entire? So is it's a very difficult action to take action about.
FYT: The third action, I turn I got requested - the direct quote follow me. he knows that the use case segment of the proposal is very limited compared to the proposal would like to see the use case proven out, right? So, the response is that, I spend some time to write a motivation and the text is very small, but you can go to the proposal slide I put in the readme. And basically describes the motivation of that. So one use case is to detect missing feature. And therefore, we can use that to trigger import of a polyfill, right? So one particular You're real use case. For example, for example, one of my colleague is working, changing the closure Library than Google ship for JS to try to use as much as possible to use the Ecma 402 API. but because not all the browser support all the calendar feature or whatever, there won't be time, we all say, okay, if we have, we to have a way in the bootstrapping code to say very quickly, to detect what is supported, what is not supported. And if they are not supported, we may download one version of closure and there if they are supported in the browser, we may download a different version of a closure with a polyfill to to fill those feature. That is not supportive, right? And it have to be a very small amount of code and bootstrapping, so this API can provide a way, you know, for example, you can using this word very carefully, get fingerprint the browser support with a hash right? Nothing or print the user because all the user using the same browser version will have exactly the same fingerprint result of that browser. It might cannot, you cannot use that detect particular user, right? Just connected can detect a browser and use the hash key to load the API a different version, right? So you miss it, you may loading a general version that, you know, the closure API, haven't seen that with additional support. I mean polyfill, but if the bootstrapping code to say, about this, this whatever, All the returned, all the calendar support. I have hash to the same thing. We have you can load a closure API which only called the Intl 402 api directly, right? So how how to be way and have their shorthand small amount of bootstrapping code to do that. So that's one of the use case to help very easy detect missing feature. in
FYT: the other thing use cases server-side programming. For example, you know, JS is of course. not only designed for a client, although clients probably one of them biggest usage, but you can also run JS on the server. server is already very popular and you may need to figure out It out, you know, the JavaScript running on the server side may need to respond. So let's say the user Say Hey I want to write a calendar purely JavaScript in the server, sign to receive the user interface from the user and output 'html to the user from the server, Java script and may have a UI to use all the calendar or the times on the hown support, right? then the server After asked the V8 in the short words say, hey, no, you're the vam might know that J server Walk out on what time zone. Do know, and then it will return and it will format HTML and return to the client, right? So this is useful for server-side programming.
FYT: The other use case, for example, you may have some because I think early on people mention say, well, if they're used this only use cases for picker then Why don't we just put in it? HTML. But how about if you have a pie you want to use JavaScript in, a non HTML environment? Let's say you want program webgl video game. A virtual time, you know, whatever can write clearly extent webgl 3D there, no HTML inside and you have all the 3D rendering and your character walking to a particular store, and you may have some place, have to have change the option. Everything showing up is 3D webgl, you cannot address by adding a HTML widget, right? Everything is webgl there. Unless you also want to work on webgl timezone picker there. So, just the three of the options. I mean, to show you that this is needed to for addressing Being fast way to do a missing feature detection, and probable can combine for bootstrapping process to download polyfill code or missing feature detection. Server-side programming is very necessary and of course, their client side programming and also some environment that using javascript not under HTML, which cannot be addressed by HTML picker have to have to increment that there are real Pretty real. You just can't face it. May be no one to work on this project as all very non-fictional use case. So I address that so I put it there including the motivation, which may be small tasks probably, similarly repeated what are just described but I put on together. So that's my response for that three action item to resolve the feedback. We receive in in May, that will convince you to do. This is a proposal that already fulfilled, the burden as a champion for this. So let me come back. So I'm here to ask for stage 3 advancement. So basically the entrance criteria from my understanding, is there how to have a complete spec tax and a Believer as down we have designed definitely reviewer. Take a look at that. So we'll have a developer take a look at it and we also got support from Several several member doing the TG2 solve the member Express support. They just expression. Are there Are there non-blocking position?
SFC: I just wanted to say that Frank has had a very good attention to detail on the proposal. He's been working on it for quite a long time. And he takes everyone's concerns and resolves them in very careful ways. From a quality point of view I think this is a very good proposal. I think that it fills a void an Ecma 402 that we've had for a long time. Frank already went over these cases on the previous slide. And I really support this proposal. It's taken a long time to get to this point and I'm really excited to see it hopefully advancing to stage 3 today.
USA: Great. And next up, there is me. So I just wanted to clarify a little on the ship all data class so I I reached out to you via after the meeting and we talked a little about this and I share her concerns. So the idea is I think as you mentioned it's hard to say to say what all means when When you say ship all data. So I think a better way to turn. This would be to ship a consistent set of data. The the concern was that, you know, it's okay to not support certain currencies, it's just not, okay to support a different set of currencies or sorry, enumerate over a different set of currencies than what is supported in number format. But as you pointed out, this is Is not a problem that is unique to this proposal and also Yulia mentioned this. But what is written in the last meeting. it's something very general to ECMA 402 and I think even before this proposal came along they were two sets of currencies technically being supported by displayNames and by number format. So I think this needs to be addressed on the 402 level but I do think that, since this would likely happen before proposal reaches stage 4, you know, there might be some normative change that would bleed into this. Given that people generally already believe that this should happen, that different sets of values should be supported, it's fine that the committee give consensus on that is it's just that the current spec might allow and implementation to potentially, you know, support different sets of units across the info Constructors, which shouldn't happen.
FYT: So, let's say we don't have this proposal. Will the thing describe still happen?
USA: Yes, it absolutely does. This proposal just exposes this issue in Ecma 402 which is why I mentioned that this needs to be addressed in a normative request to 402. However, that normative pull request might and probably will induce a normative change in this proposal.
FYT: I see, got it.
SFC: Yeah, I agree with everything Ujjwal said and I think in general the basic goal that we need to achieve is that if there's an Intl object that supports some list of things, let's say calendar systems, let's say Intl date-time format supports a certain set of calendar systems, that set of calendar systems needs to be the same one that the intl enumeration returns, which seems obvious and we just need to do some - if it's not already fully in the spec - we just need to do editorial work to make sure that that's the case. Because that's the expectation that developers have and it also helps this data consistency issue.
USA: Perfect. Yeah I think as we're on the same page with that I think that also addresses Yulia's concern.
JHD: yeah, so I think what Shane is saying is the same thing that I put on my queue topic which is just like we should be able to just rearrange the spec to make sure that anything that the enumeration stuff reports exactly matches, what supported everywhere Right. And like and that way rather whether the full data set by whatever definition that is like. It doesn't matter how much of it is shipped, at least everything will agree and be coherent. Does that sound like what Shane was saying?
USA: I think it does. Yeah, I think we are all in in complete agreement.
FYT: It seems like we agree upon that one as a separate issue, but is there anyone who will drive that? It seems like we are saying this is the right thing but nobody will do anything.
USA: I had one idea. I could volunteer to okay, focus on that.
FYT: Okay, that's great. I don't want to have everyone say that we agreed on this as good thing and then no one takes ownership of it.
SFC: I opened an issue to help track it.
IID: Okay. So Yulia is currently happily asleep. So I'm stepping for her, but there's been a fair amount of discussion of what Yulia’s concerns had been. And so in general, I think they've been well-addressed. I'll just go over them quickly to sort of clarify where we were and then agree that we think that they've been addressed. So, Mozilla is willing to accept the proposed use cases. We agree and approve of this idea of making sure that the lists of which properties are supported, should be kept in sync between features. And I think that that makes sense to be addressed at a level higher than this individual proposal. So it doesn't need to be a blocker there. And then in terms of the shipping same data thing, I think there may have been a little bit of miscommunication happening there. So, I've gone back to the source of this original recommendation, which was our internal privacy review. And the key thing there was the idea that there should be no observable differences between two users using the same browser version on the same platform, irrelevant of their browsing behavior patterns. So this is like what Frank said in terms of fingerprinting the browser versus fingerprinting the user. The point that we wanted to make clear, largely as a normative idea, is that it would be bad, for example, to have locales installed on demand. So if you asked, which locales are available, that would depend on the user's browsing history. I think that a bunch of Frank's presentation took this as a given and we just want to clarify that it is probably important to point that out explicitly. But that being said, I think Mozilla is happy with all of the responses, and we have no objection to advancing this proposal.
USA: I think few people had some doubts on the chat. I hope this addresses all of that.
FYT: So I would like to ask TC39 to support to advance this to Stage 3.
SFC: I support it.
JHD: I support it as well.
[other support]
USA: So this is great. You have stage 3.
FYT I just want to make sure that Mark is happy with this.
CM: I think I can speak to Mark's concern, I understand his concern fairly well and I think what you have come up with does address it.
FYT: Thank you, thank you. Okay, so I guess we got stage three.
Stage 3.
Presenter: Caridy Patiño (CP)
CP: Hi Folks. We're back with Realms. We have been talking about Realms for the last few meetings. So we'd like to go over very quickly and open the discussion about some of the topics. Probably everyone that has participated in the last few meetings already is aware of the API. It has a very small footprint API. From the last meeting, we have three main observations of things that we have to look into. We wanted to get the stage 3 reviews resolved. We also wanted to make sure that the HTML integration spec is ready, specifically for the module mechanics. That was one of the contention points during the last meeting and the general feedback was that implementers were not sure what they are gonna do yet in terms of integration. And finally, the last one was a little bit more hand waving in the sense that some of the delegates, specifically I believe Jack and Jordan, raised some concerns about the scope of this proposal. So, let’s go over these three items individually.
CP: in terms of the review we have received a considerable amount of editorial reviews and feedback in general. Thanks to everyone who has contributed in some way or another but we believe we have addressed all of the concerns in terms of review.
CP: In terms of the HTML integration, Daniel has been working on this for quite some time now. This time around, he was able to finish the HTML integration changes that reflect the discussion that we had during last TC39 which was mostly around the module mechanics and specifically the caching mechanism for modules. And we believe that the pull request is ready, there is one more thing about HTML integration that we haven't worked on yet but we also agree in previous meetings, that it was a stage 3 concern, which is really to define the global names that will be added to the global object when the new realm is created, those are stage 3 concerns that we are going to work on once we get to stage 3. If you have any questions specifically about these, I think Daniel is around so we can go into the details of the HTML integration if needed.
CP: In terms of the concerns around the scope of the API, during the last meeting Jack and Jordan raised some concerns, mostly the concern was around the direct access to objects from another realm and which is sort of what you would do if you're using an iframe in the web platform. We had extensive discussions about this, in the plenary and in the SES meetings on a weekly basis. Jordan joined one of the SES meetings recently. After all these, we, in the champion groups, believe that the callable boundary specified right now is the right approach. We have also been able to validate that even with the callable boundaries, you will still be able to emulate the direct access to objects from another realm. If it doesn't use cases, you're trying to control or part of the use case, that you're trying to fulfill, you'll be able to do that by using membranes. And we have some of that as well, just to recap and I believe is important that we all understand that we have been working on this for many years. Now, the main goals remains to be Remains the Same. We wanted to have a new global object and a new set of intrinsics and having synchronous communication between the two Realms is also very important and the proper mechanics to evaluate code about with modules about blade source And so on. Those are continue to be the primary goal, and we have discussed already use cases, like being able to have access to the builtins intrinsic to do operations on them. And those are not really use cases that we set to be solved with this API. Obviously, if you're using an iframe for something that it will be able to access the array prototype search or something like that. You will still be able to do that. But with the Realms proposal, that's not something that is something that you expect you to do. In terms of the use cases, we have debate also for Years. Now, the different use cases that we are set to solve some of them here, some of them are documented in the explainer in details. We believe that those are very valid use cases and we believe that the current specification addresses those use cases. The callable boundary is set to be a very low level API. The realm itself is a low-level API that is meant to be used by Library authors. You need to understand what you're doing in order to use this API. I don't believe that is a controversial statement. We also understand that if you want to use this API to do more advanced communication between the incubator realm and the newly created realm, you have to do a little bit of boilerplate, you have to prepare the realm if you want to share bits with the other realm or whatever the nature of those bits are. You can also go into the extreme, which is implementing a membrane that allows you to preserve identities across the callable boundaries.
CP: We also have a polyfill that we have implemented a few months ago, we have test for that too. We actually validate one of Jack's concerns which was whether, or not the callable boundary was enough to be able to implement a membrane on top of it. So we have a very tiny Library, about 1kb, 1.5kb, very simple implementation, but a robust implementation of a membrane library. That allows you to do that kind of advanced use cases if that's what you need. Many of the use cases don't even need that, instead you just need a way to create a realm to evaluate code and maybe get access to some bits out of the realm. So with that in mind, we believe that we're ready for stage 3 and we are ready to open the debate. Questions?
JHD:. So the first one I added was, I mean if this event since this membrane library is so tiny, why not just support that directly in the language as opposed to making people add this easy-to-get-wrong library, even if it's small?
CP: yeah, we have debated also, the membranes and I think Mark Miller has done a good job explaining why we don't have a built-in membrane library yet. I don't know if Mark is around -
MM: I'm around. I can jump in to explain. The main thing is that membrane right now is a pattern. If you the that is that we universally agree on across all uses of membrane, is what a fully transparent, or a transparent as possible rather, membrane looks like. The purpose of a membrane is to introduce non-transparency. We'd love to have an agreed membrane abstraction mechanism membrane that you could parameterize in a standard way, with a distortion, but that's still research. We've got several different membrane libraries that have different perspectives on how one parameterizes with the distortion and no clear dominant approach to that. So, so what? what this? this, what the realms, Proposal does instead with the callable boundaries, the callable boundary is universal. Adequate underlying mechanism that enforces the separation. It's a safety measure such that any membrane built on top it, enables any membrane to be built on top of it, so it doesn't preclude any particular membrane that preserves separation and as a mechanism, it ensures that any membrane built on top of the can't get separation wrong. It also fortunately ensures that any membrane built on top of it. Can't purposely violate separation, so it cuts both ways. But but also as we've we've discussed, the, if we didn't either a membrane or a call we'll boundary we could still do membrane as user libraries on top of Realms that had neither separation. But that's not an argument for trying to adopt membranes themselves as the separation mechanism at this time.
CP: yeah, I want to add one thing to what, just, what marks said and is that the callable boundary? There is actually help a lot when it comes to having that membrane between two rooms and we have been working on this for quite some time and before they call Obama it was a thing and it was a common mistake when you implement a membrane to have issues with the separation and object from the other side. And so on, especially with errors and throwing errors between implications across the boundary. So it actually helps a lot to have that separation place.
JHD: Okay, and then just a real quick and then I'll move on to the replies so you're saying that there is no larger feature before you get to the points of disagreement that Mark described. Beyond this. Like there's no there's no hop between callable Realms and full membranes with a decided distortion mechanism?
MM:i Before the invention of the callable boundary, there was no Universal underlying mechanism Simply Beyond simply the mechanisms of proxies and weak maps, because put another way proxies and weak Maps, were the Universal underlying agreed mechanism. And then they were the only ones until the invention of callable boundaries. But other than that, the membrane library simply followed a particular pattern and then introduced distortions by varying from the pattern. There was nothing Universal that how they vary.
JHD: Thank you.
MM: Anybody who's interested: We'd love to have more research on this, on the idea of a membrane abstraction mechanism rather than a reusable pattern. Interaction mechanism where you had, we had a universal way to parameterize with distortion functions is something that kind of tantalisingly close, I think we actually could get there and I'd love to have more minds on this problem.
SYG:I don't know if Justin Ridgewell is on the call. It may be a bit late for East Coast. I assume he's not so I'll kind of speak with him but not really. It's my understanding, which is non-experts understanding I don't work on AMP, that the amp DOM worker use case can readily leverage the callable Boundary to move whatever it needs to do with the virtual DOM for running amp scripts should be a synchronous thing which is what they wanted all along without the need of a full membrane without a callable boundary exists. So there is a concrete use case that doesn't require the membrane pattern, but can still use callable boundaries, that kind of separation to do what I want. So just that's just the point that this is useful as people as a building block beyond membranes.
CP: I believe you are right to discuss this. We studied this extensively and there are many, many use cases that do not require the membrane. The membrane is only needed when you want to really preserve identity across the two rooms and, which is a very edge case and there are many other use cases, just simply I've only code and get the result back and send it over. What did you stringify that using JSON stringify for? Just share the bits, or whatever shape, or form sharing the information that you want, if you need to share information,
JRL: AMP wants the callable boundary. If we don't have it, all we're going to do is implement it in user code, because we don't trust ourselves to use the object-passing form of Realms correctly. Somehow we will leak an object across the graphs and that will allow the semi-trusted code to access the AMP global. Our reason for using Realms in the first place is to disallow that.
JWK: So, I have a question about callable boundaries. Is hypergraph membrane still possible? It seems the hypergraph membrane needs to track identity across different realms.
MM: The hypergraph membrane is the thing that Alex Vinvent Invented where you have several different sub graphs. Not just two but several, that are separated and that there's a shared identity tracking between all N sub graphs, and that furthermore, that the the number of subgraphs being separated can be dynamic, which is, and at Alex Vincent’s extensions, hypergraph membrane mechanism did all of that rather elegantly the underlying with the normal membrane mechanism you have the Simplest to a membrane. The way we originally did. It was a blue to yellow WeakMap and a yellow to Blue weak map for when you're just separating two and you're trying to make corresponding identities, you're trying to do a hyper graph instead, what Alex came up with, which works very well, is that you've got a yellow to Shared record and a blue to Shared record and a green To Shared record WeakMaps, all of which map to a common shared record and And then, the shared record has symbol name property for each of the sub graphs mapping back to the identity for that sub graph. So you can, you can be compactly map from any color to any other color by going from the representative of that color to the shared record and then going from the shared record to the representative of the other color.
CP: I believe, so I don't know all the details of these, but it sounds very familiar. I've been implemented, many different membranes throughout the years, haven't found anything, specifically, that kind of be done and they mechanics are really simple. If you take a look at the fermentation that we did on top of this API is very straightforward. You need a WeakMap, map, you need identity of object that you want to share to go through the gullible, boundary has a function on the other side and it works, Pretty simple. As Mark said, this is just the foundation of the capability to implement any kind of membrane on top of it. We can look into more details, but I'm pretty sure that supports this. I just don't have enough details about these type of membrane specifically, but it looks a lot like what we do. Anyways, the marshal shares the identity across all the different sandboxes and then whenever something happened you have to go to the Marshal, to do the operation there, and share it with the other, some box, or the other realm. So it looks like we're doing literally
MM: It's not as clear to me. The thing with the Alex Vincent representation is that the record that you're mapping to your map is, Represents the should identity, and it's not within any one of the boundaries it's a shared thing between all the boundaries,
CP: well, the record belongs, a realm, it has to be in some Realms and if he has to be in zone realm, then should not be a problem to be able to to guide to that realm. It has be in a realm
MM: That's a good point. So if we, if you have realm who's perfectly, okay? So basically you have a switching realm, they a realm whose purpose in simply to represent the identities that are shared between all the other Realms. And then, basically, you're going through two callable boundaries to get any crystal wall to get to any other useful realm. Okay, that makes sense
JWK: Okay, so I guess the answer is yes. My next question is, if we have to use a membrane library instead of the built-in support, when debugging objects across the realm, it will step into the realm library and it's a pain to debug.
CM: Yeah, debugging a membrane is hard. The good news is that we are Salsforce funding. some work for an Igalia to work on helping improving some that. But in general, you're using proxies, the debugging experience is more difficult than regular objects.
MM: I wasn't aware of the Igalia work on helping to debug this.
CP: In general those are the problem debugging and again as only, you need to use a membrane, you don't need to use a membrane, This is not different from debugging an iframe today. you have different identities depending on where you are. And they have to have accommodations to support the Realms and be able to Allow you to identify what realm you are on and so on.
JHD: I'm glad you're here because was hoping for some clarification here both Realms and amp has been around for many years and I hadn't heard about AMP having any use case related to Realms until the callable boundary thing came out and it's been like lightly mentioned a couple times, so I'm not super clear. I hear you that callable Realms solves the problem for you and that amp wants it. So I'm curious is it a problem that cannot be solved with the previous iteration of the realm of proposal or would not be solved with membranes. Like maybe this is smaller solution, but do they all solve your problem or not?
JRL: Yes, every Realms proposal that's been presented solves AMP’s use case. The difference with the old proposal where we were allowed to share objects directly across the graphs, it's easier to shoot yourself in the foot. So what AMP currently has is essentially the exact same thing as a callable boundary, except we're talking across web workers. We serialize the entire graph into JSON and post that across, and then deserialize it and that separation guarantees that we can never share the object across the graphs. Someone who's unprivileged can never access the AMP global object. With the old Realms proposal, that's not a guarantee. So what I was going to have to implement is essentially a callable boundary where you're not allowed to talk to the other side at all. All you're allowed to do is call my post message helper, my post message will serialize and deserialize on the other side, and then you would do it that way except now it's sync instead of async. So we would be implementing the exact same feature as the callable boundary. Just, it would be a user land now.
CP: Yeah. So then we call this Y 2 Jordan, the terms that we use for that is integrity preserving, semantics of the callable boundary. So if you just cannot share that the object.
JHD: So just to clarify, again, Current the boundary API does not permit any way to get direct object access access, and you're saying that's safer because it just does what you want already and handles all of the separation for you. is that accurate?
JRL: Correct. We don't want to share objects. We only need the ability to run on other code without giving them access to our globals, the integrity boundary.
JHD: So just as a brief thought experiment to make sure I have the understanding correct: if the old Realms API had some sort of constructor option that like opted you into this mode, such that you didn't have to worry about it, would that achieve the same goal for you?
JRL: Yeah, that would be fine with us.
JHD: Okay. Thank you for clarifying.
GCL: I feel like a lot of times this conversation about object access turns into this, like membrane thing and think the whole you know, privileged access use cases. Clearly very important, a lot of people here care about it. and I don't want to say that we shouldn't have that. I think it's totally reasonable that. We have that. But there are also lots of use cases That Don't have anything to do with that. Right? Realms are not just a security mechanism in the way that it's being used here, but they can also be used to, you know, bootstrap environments for, you know, mocking platforms and access and clean versions of objects for, you know all sorts of things there, a lot of use cases, you know and in node we have VM on the, on the web. there's iframe obviously and there's a lot of code that uses these Primitives for things that are not. The like membrane call separation thing that is being forced in this proposal here, and I think that's really unfortunate if not for the, you know, alone. Just the fact that this code can't be reconciled right to be code. that works anywhere, right? You have to use iframe code in the browser and VM code in node. that's unfortunate by itself. and so, I think it would be like Jordan said, write a sort of option. You could, you know, opt-in opt-out I don't think it really matters to not have this limitation. I think would be a lot more representative of the use cases that this proposal can serve because I feel like it's very one-sided right now.
CM: Yeah just two just to share that in the previous proposal that was a getter on the input of the realm. That get a give you access to the global object that was removed. There's nothing that prevents of adding that in the future. If we feel that that's really what is needed. Just that at the moment, we believe that's a foot Khan and it's very error-prone. And yes, they are previous around that, like, the iPhones and the DM toes come with without issue the identity. This Tissue.
DE: so, I'm kind of having trouble following some of the discussion about use cases because I get to their use cases for shared objects are almost but they're also use cases. Many use cases presented for Caldwell boundary problems and the existence of one class of use cases doesn't negate that the other class. So I could I can see the argument for for adding this a good proposal but I don't see why this gets tied up in that other one. This realms proposal meets, the use cases that the champion group has the champion that, you know, presented the motivation and brought it to stage two. So, this, you know, the current the current path makes sense to me, even if it doesn't everybody's problem.
JHD: So to be clear, at the time it was brought to stage 2, it solved the shared object use cases also, so callable boundary is effectively a brand new proposal that happens to solve some of the use cases of the proposal that went to stage 2. So it's I think it's not really fair to characterize this as like, "oh well, these are just two overlapping proposals" because essentially the stage 2 proposal was kind of replaced - very recently - with one that does not solve all of the use cases that the stage 2 proposal solved. The fact that the champion group only has a subset of those use cases, doesn't also negate that the stage 2 presumption we all had was that all of those use cases were solved and that's what my next sort of queue item is about.
MM: Yeah. Historically, JHD is correct, The Realms without the callable boundary. Certainly enables the call, the boundary, to be built at the user level. the thing that solved by building the callable the boundary in is enforcing isolation. And if the isolation is optional, then it's not something that needed to be enforced by an inescapable mechanism in which case building it into the platform is, is with note is no longer solving a fundamental problem if you make it optional, because the only fundamental difference between providing at the user level and providing it in the platform is that the is that we can make it non-optional by putting to into the platforms. So, once again, historically I think it's the the way we ended up here is that some of the people objectioning to the nature of the stage 2 proposal wanted to make the isolation mandatory. So I think I have trouble characterizing this as well. If we want to make it optional, can add an option to make it optional in the future. I'm uncomfortable with that because if we wanted to make it optional, then I agree that we shouldn't introduce the callable boundary in the first place. But, what we found was we were deadlocked on moving it forward, whereas the callable boundary meets the use cases that most of us have in mind, That would be happy either way. And satisfies those who want to make the isolation mandatory.
LEO: I just want to talk a little bit about this problem here, because we are talking about, like, if we've had the only option, Forward, current common boundary. What? We've been talking here, we are identifying its cases. There are sold this way and wouldn't be resolved with the full object exist and we considering like the other parts are things that are currently hard blocked by consistent reasons, they're valid and we already raised here. they start with problems from the identity discontinuity Etc. So these have been consistently blocked for a long while now and we are finding a solution where we are resolving many use cases for things that people want with object access today. That's because of this is the classical way to solve other use cases today, but these can be mitigated with membranes today. are membranes complex?? Yes they are. But that's one way to use the current Realms API. The same problem is these same use cases are solvable today in the web reality. No one loves to use an iframe, but what we are solving with the callable boundaries, we are solving, like, we're solving problems that we cannot solve today from using an iframe having a proper. Sandbox coat as sandbox. We are solving things here that we that we cannot solve today through and for the other things with object access, this somehow exist today, both in Node, both and, and in the web, it's just not the way, Like, we might prefer. This is like availability, so the callable boundaries are not only solving like a large chunk of the use cases. They can also make themselves compatible, like me to mitigating with the immolation from membranes. But also like from what is available today, ready? but like the callable boundary allows the resolution of use cases that you cannot resolve today properly. Because what is available in the web today doesn't solve the goals of this proposal. And I'm really excited to see this moving forward because what we are resolving here, we are resolving things in a very interesting way that this is opinion for me, but it's an interesting way to resolve these cases and we are going to be resolving things that is just not available today in the web. And I hope we can make this to become available.
USA: next up, we have Shu. Who says that he agrees with Mark and that the primary value add of built and isolation, is that it's not as capable. Next up is Gus. Yeah,
GCL: I just the thing about membranes. Being a solution for this. while it's like technically true, it really bothers me that, that is phrased in that way because it doesn't really represent the usage of the future. Like if someone's trying to set this up in a way that has nothing to do with, You know, the whole, whatever security model this Champion group has thought up. Like I'm, I understand that there's a whole thing there. It's anything that I'm familiar with, and it has nothing to do with the reality of how I would use this feature. And now I need to, like, come in and understand this whole model to do something completely unrelated. It just doesn't make sense to me and I don't appreciate the connection there because it's just not it's just not a it's just not comparable in my opinion and I'm sorry if I'm not phrasing this.
MM: can I ask why it's not comparable? The membranes are the at the default membrane the membrane in the absence of the distortion is trying to be as transparent as possible. So other than the internal and in assume that, that a transparent as possible membrane Library, does come with this in practice there shouldn't be much observable difference between the callable boundary with a transparent membrane on top versus the direct object access that you might prefer. So given that the membrane Library It is easily available. What's the difference that you care about between that and the direct object access?
CP: Yeah, I want to add that I think Mark is I would write the example that we create with tiny membrane that I mentioned, I call it. I-realm instead of Iframes and is exactly what you will get with and I present you with it. When you create a friend, you insert it, you get the window out of it. And now you start interacting with it. You're getting some objects that they have different identities that you try to check the identity. If they do not match your identity and another exactly what you're gonna get. if you have a library instruction that does that for you? again this is only if you really need to have identity across the realm boundary. So if you are interested on objects that are on the other room and you need to hold to that identity. Because either you wanted to share it later on, so, or do something with identity. If you don't care about identity like the case of amp or many other use cases, you're just fine. You don't need The membrane or if you need, you is just a simple abstraction at the user level, level, bring a library does the extension of the realm that give you This thing that when you created, you have access to a global this and that globalThis happens to be a proxy of the glow body from the other side. And and it works just fine, just like an iframe, you don't see difference.
GCL: Yeah, no, I understand that it technically works if maybe like this the now like say that TC39 saw that symbol polyfills right, which use like strings weird prefixes in them. We're doing well right? And they said oh well these work we don't need to do anything and like it technically worked but it's just it's like a weird tacky work-around to do something that should just be a different Way. And that's sort of how I'm seeing it. I understand that like membranes can nothing technically, but it just seems like a very complex weird work around to something that should just naturally exist.
MM: We have blocking objections to providing direct object access. I mean, that just the reality of trying to advance this thing is that we've got blocking objections to providing direct object access. Which why the callable boundary was necessary to having a proposal that could advance.
GCL: Yeah. And they objects like having an option too right?
CP: Apparently yes.
GCL: Okay, that's already. I don't understand that but I'm not going to block this proposal. Either way. I'm just very perplexed about it.
JHD: I have a clarifying question there, Caridy. if I call another Realms object function and pass it string and then is the object I get back. Does it have the internal Slots of a string?
CP: Nope. Nope, you're getting a proxy. The proxy does not have the internal slot, right?
JHD: So, Okay, yeah, thank you. As Mark has pointed out, there have been some blocking objections by folks who are represented by people in this room, but who have not debated these objections directly in this room. It's my understanding that this is basically saying the capability (that browsers and node users already have) should not be something we permit in a new API for "reasons". All the arguments I've heard are very good, compelling arguments for what the default should be. The default should be what Justin and AMP needs - which is the safer thing, where you can't escape the abstraction. That's a very compelling argument, but none of those arguments preclude the capability, and there are use cases that require the capability. I specifically had these cases where I need to get objects with internal slots. A Proxy to it is not sufficient for built-ins like that. I could probably write a wrapper that like, detects an incoming thing with slots and reconstructs the thing with slots coming out, but that's going to very difficult and very easy to get wrong. So I guess it's if I think it's like my personal feeling is that 90% of the people who want solve this problem in this room, and that's a ballpark number. Some will have their use cases met, and we'll have much lesser, much reduced forms of motivation to advance things, and the people who have created this sort of deadlock and forced callable boundary Realms as an alternative will not have ever needed to come into this room and argue their points directly. They'll they have only done it by proxy, and that is very frustrating because It doesn't solely matter what use cases the champion group has - the proposal as it entered stage 2 solved a set of use cases. The champion group may only cover a subset of those, but all of those use cases are what were met. The stage 2 criteria means we expect the solution to go into the language, we agree those are these cases we want to solve. This approach is effectively magically creating a new proposal that's already at stage 2, somehow - and asking for it to go to stage 3 while simultaneously magically discarding the existing proposal. I'm saying that in the sense that some of those use cases are no longer achievable.
MM: I want to object to Jordan's characterization of the (?).
JHD: And I tried to word it very carefully because I'm not trying to imply bad faith
MM: Well, the purpose of the stages is to adjust to adjust the proposal in reaction to objections that are raised and in doing that the proposal changes and the use cases that it meet changes. I don't think that seeing this as qualitatively different than the normal process of adjusting a proposal in reaction to objections is a fair characterization. I think that Is simply what happened here. We can disagree with whether these were the right adjustments, but it is simply adjusting a proposal as it advances through these stages in response to objections as the stage process was meant to support.
CP: Yeah. And also want to add that I think is a mischaracterization as well. I believe true as percent the Google has presented concerns Yulia has presented concerns I think they have represented well and we have X extended discussions around those independent plenary.
JHD: I do not feel like there have been extensive discussions about those viewpoints in plenary. There's been a summary of them and allusion to them, but I just, I have not heard any. I do not feel like I have, I've been attending every plenaries for a long time now. And so, I haven't any, and I don't feel I have heard any opportunity to fully debate. The belief that the mere existence of a capability that already exists and can never be removed is a problem
CP: the second part of your statement is also the collective. At this point, we do want to continue working on this proposal. We have already ideas that we want to explore including the maybe the possibility of getting out of the deadlock, with respect to access to object for another realm as I mentioned before, just a of. We need to put out the work and if people who start using this API, once we get it out there, start providing meaningful feedback that this is not enough for the use cases that they have. We will have champion group that goes on. Like that. There's There's nothing wrong about it.
Greg: we actually formally figure out whether or not we can move forward with stage 3 or not because I do have a concrete question to Jordan. but I don't want to like, because we only have 10 minutes like how do we go about doing that? Like with Jordan’s frustration about potential addition like negate requesting that or what?
JHD: as far as whether we have more time and stuff, that's a something that we can talk, ask the chairs in the committee I think. But as far as just to see if this helps, if I believe that there was a good faith path to direct object access meaning like there's just some things to work out and then we can pursue it. I wouldn't really have the same concern. I'd unhappy with the current situation but I would be I would be content, but I have give been given no indication that there will ever be budging of any kind by the folks that are blocking direct object access especially if the most, the majority of the impetus to solve some places. All of these cases
Greg: I have a fundamental issue with a non technical argument being something that walks progress of a proposal because there's nothing precluding us from unblocking like that's essentially the argument against objects.
JHD: Direct object access is also in non-technical one. So that seems to be the situation We're in.
MM: The argument against direct opposite object access, whether you agree with it or not is a technical argument. the technical argument, is that Shu, You're the one who is the closest that I know of to a representative in the room of the objection. So, please correct me if I'm characterizing the objection wrongly here, but the objection as I understand it, is that if forums are provided, people will try to use it as effectively and isolation mechanism. Call it a security mechanism. If you wish experience and I'll agree with this from the Agoric experience, trying to do, ad hoc isolation on around boundary, with direct object access shows that it is terribly easy to get wrong. It's incredibly easy to make a mistake, such that objects leak, that can be solved either by having well debuggable available libraries like membranes or like your user level calledable boundaries. but the objection is people will underestimate the problem. preserving isolation with ad hoc libraries at the boundary, people will get it wrong. And we will then have security bugs as a result of not having had an enforced reliable isolation
JHD: So we basically switched from the “only has the foot gun / capability” version to an “Only lacks the foot gun / capability” version. The other option that I would be more interested in is something that defaults to the safer, more restrictive one and allows opting in to the wider, more powerful, but easier to screw up version. To me, that would solve all of the use cases presented. I know without having that version available and regathering the evidence that SYG was talking about. I don't know how to confirm that guess. But my guess is that if we named everything appropriately, whatever that means, that we would be able to convey the risk and reduce the footgun likelihood. So that's what I'm interested in seeing.
CP: That's something that we can work on. Now that log is real like implementers specific to Google and Mozilla we're gains allowing them the direct axis and we have to work on it from the feedback that we get from users. At this point is is all about what people wants to use or do we These API because we need to get there first.
LEO: Yeah, I also want to express Jordan and it's surprising say like you see. No one's saying in good faith that the plan to to move this forward after this. I remember like we talked about this, I think about this where I told like I have plans, I like my team is going to be working on it like ever much more to explore on it. And yes, I we already collecting feedback from Community. is so much to work through this with like, the Chrome team has like, should destination like to get repaid at. There is Beauty in their decision and That's good. Like, in order to do that, I need to be able to gather data to counteract your counter argument for that and saying like the usefulness and work through this. and I believe we can have so much more material with this callable boundary because like otherwise its a hard blocker. For us and there's so many use cases. This is already making available but there's so much more. We rely so much today on the usage of Realms. So if we are definitely not invested in just like this API in that work done. There's much more, much more explore from this. This is what I talked in async, but I also make this public here and,
SYG: I think Jordan would if I read you correctly, you were directly addressing Chrome in the good faith path forward. Not not that the champion group right now, the champion group.
JHD: That's right.
SYG: Yeah, so that's correct. Let me reply to that. I think the currently the objection stands that we don't want the d and we don't don't want to direct object access and don't want the option partly, because of the point that Mark has already made that a big part of the value of taking the engineering effort to build in isolation into the platform, is that it's not a scale form and perhaps that could be overcome with education naming, it something like super unsafe expose direct object access or something like that. I don't know. That is a possibility but at the same time, the other half of the reason why I don't look at. So I have to kind of to kind of counter arguments to your counter argument. So one I don't personally Find the “get Originals” use case very compelling. We've been through the get Originals thing. This is slightly different, but I find that to be an even more niche use case than the membranes. One is despite the complexity and the difficulty of using membranes, Salesforce products and AMP do great reach. So I'm kind backing that into into calm, weighing it, it's less clear to me. despite some of the delegates, personal use cases here for wanting direct object access the true reach of that side of the expressive of the expressivity. And the second counter argument to your kind of argument is kind of I agree with what Dan has been saying. Was that Yes, the scope of this proposal has been reduced to your disagreement but it sounds like because the scope was reduced in such a way that this proposal no longer Directly address these, your use case you would rather not be other half of the use case, go through either. and that's why I don't quite understand, that's not really an argument for not allowing the other half of the use case to go through. Even if there were no path open to address your use case.
JHD: So maybe another day I'll discuss that.
USA: Okay. Wait, we're at the top of the time box. Thank you everyone for the discussion. Do we want to continue this at a later time as an extension?
CP: Well, first I would like to ask is if there is any objection for stage 3 at this point.
JHD: There needs to be discussed out before we get to that question.
SYG: Is there anything that we can work through to we re discussed it? And what are the available slots for continue this discussion?
JHD: I think there needs to be more discussion in plenary before we can get to that question.
USA: Yeah, I think we have a lot of free time so I think if you figure out I think day three would have a lot of free time.
Queue topics from DE: New Topic: Disclosure of Salesforce/Igalia collaboration: Detached iframe debugging, Proxy profiling/optimization, Realm spec New Topic: Describe HTML integration, ask for feedback
Continue conversation later in the week