LGTM3. -mike
On Thu 9. Sep 2021 at 22:22 Daniel Bratell <[email protected]> wrote: > LGTM2 to the plan and comments outlined by Chris. > > /Daniel > On 2021-09-09 22:18, Chris Harrelson wrote: > > Hi Glen, > > Thanks for your patience while we (collectively - your team, API owners, > and others) worked through a response to your request. > > The API owners met today and discussed this request to extend the Origin > Trial. Here is some new data I got: > > * The team showed evidence of recent further engagement with partners and > getting as soon as possible to the v2 you mentioned. The Web Payments team > also signed up to help accelerate that. > * There is new evidence (to me) of the potential & importance of this API > for the web that I hadn't considered. This would really help the web > platform be more useful, IMO. > > I'm still concerned about the length of the trial and its impact on > burn-in and other risks of a long OT. But I'm now ok with approving this > request. > > Finally, we also concluded that because of the length of the Origin Trial, > it's outside the bounds of approval via one LGTM, and requires three. So > please wait for two more LGTMs. > > LGTM1 to extend this trial to M96. > > > On Thu, Sep 2, 2021 at 9:32 PM Glen Robertson <[email protected]> > wrote: > >> Hi Blink Owners, >> >> Have you had a chance to consider this yet? We are quickly approaching >> the end date of the current OT (2021-09-14). >> >> On Fri, 27 Aug 2021 at 14:56, Glen Robertson <[email protected]> >> wrote: >> >>> Would it be possible for us to extend by 2 milestones to M95 (inclusive) >>> instead? We believe we can get a new v2 API (which will be a significant >>> breaking change) implemented in time for M96; M94 is already in beta and >>> M95 will not ship on CrOS, so the earliest we can get new code out to >>> developers is in M96 anyway. This would make our total OT timeline M88 to >>> M95 (8 milestones total), which is within the maximum OT time limit of 8 >>> milestones Alex mentioned above (in fact shorter total time due to the >>> changing milestone period). We would very much like to avoid the disruption >>> to developers of having the OT turned off and this functionality being >>> entirely unavailable during the intervening period before the new OT starts. >>> >>> We understand your concern about an extended OT risking burn-in, but >>> this is a complex API for developers to start using, as they have to create >>> a product and payment flow around it. Usage of the API is still low — a few >>> hundred calls per day total for all methods (excluding >>> getDigitalGoodsService, which is used for feature detection even when >>> the API is otherwise unavailable). >>> >>> Shipping a subset of the API now wouldn't help because we are proposing >>> breaking changes to enough of the API that it probably isn't useful to ship >>> the rest. Also, we are proposing a breaking change in the behaviour of the >>> feature detection function that must be called before any other calls, so >>> it would be mildly risky to ship that immediately. >>> >>> I have made a draft version of the proposed v2 API publicly available >>> <https://docs.google.com/document/d/16r8ZM_vTMNroB_JkoyKF9jdgiMNZXc2z7OfnsPYp8l4/edit#> >>> (though it is still being reviewed). It will be a significant breaking >>> change to the API. >>> Thanks, >>> -Glen >>> >>> On Fri, 20 Aug 2021 at 06:33, Chris Harrelson <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> The API owners met to discuss this intent today (Chris, Yoav, Alex, >>>> Mike). We're glad to see you are still pursuing the API and responding to >>>> feedback with the v2 API. >>>> >>>> However, 9 milestones is very long, much longer than we are typically >>>> comfortable with, and within the range where there starts to be substantial >>>> risk of burn-in. That combined with the v2 design being neither publicly >>>> available nor implemented yet, leads us to conclude that we can't support >>>> extending the current Origin Trial, since there is also no >>>> defined experimental justification for doing so. >>>> >>>> You can of course come back and ask for a new Origin Trial once v2 is >>>> public and implemented. >>>> >>>> We also discussed two other points: >>>> * There is the option of shipping a subset now, but we were not sure if >>>> there is a useful and stable subset that could be shipped. >>>> * If v2 were implemented now and you wished to transition the Origin >>>> Trial "smoothly" to the new API, that would have been reasonable to >>>> consider. Reason being the purpose of an Origin Trial is to experimentally >>>> fit an API to purpose, and a change to v2 is a strong signal that there was >>>> experimental feedback justifying it. Further, a breaking v2 API would >>>> reduce burn-in risk. >>>> >>>> Thanks, >>>> Chris, on behalf of the API owners >>>> >>>> On Mon, Aug 16, 2021 at 2:17 AM Glen Robertson <[email protected]> >>>> wrote: >>>> >>>>> Hi Blink Owners, >>>>> >>>>> We would like to extend the DGAPI OT further. Requesting an extension >>>>> to M96 (inclusive). >>>>> >>>>> Note: that is 9 milestones total (8 on CrOS), some of which are the >>>>> new shorter milestones. Also CrOS won't ship M95. >>>>> >>>>> We now have an updated API design <http://go/dgapi2> in internal >>>>> review (sorry, Google only for now). I plan to update the public explainer >>>>> once the design is internally approved, then start on implementation of a >>>>> revised "v2" API. I expect implementation to take another milestone at >>>>> least, but like before we can't make promises about getting the >>>>> engineering >>>>> part done within a tight timeline. When that is ready, we will want to >>>>> start an OT on that revised API. >>>>> >>>>> Also M94 (the existing post-end milestone) has already branched - do >>>>> we need to merge something to ensure DGAPI OT is not turned off for M94? >>>>> >>>>> Thanks >>>>> -Glen >>>>> >>>>> On Fri, 14 May 2021 at 10:19, Matt Giuca <[email protected]> wrote: >>>>> >>>>>> Thanks Alex and Yoav. >>>>>> >>>>>> On Fri, 14 May 2021 at 05:24, Alex Russell <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> SGTM too; LGTM! >>>>>>> >>>>>>> On Monday, May 10, 2021 at 3:54:37 AM UTC-7 Yoav Weiss wrote: >>>>>>> >>>>>>>> On Mon, May 10, 2021 at 10:35 AM Matt Giuca <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks for the explanation, Yoav. >>>>>>>>> >>>>>>>>> Yes, we are talking about 6 milestones total (note: 5 milestones >>>>>>>>> on Chrome OS, which is where a lot of our customers are targeting, >>>>>>>>> since we >>>>>>>>> missed the first milestone there). >>>>>>>>> >>>>>>>>> As said above, we are anticipating a V2 origin trial at some point >>>>>>>>> in the future. We think we'll have a pretty solid design by the end >>>>>>>>> of the >>>>>>>>> quarter (that's roughly corresponding to the start of M94) but we >>>>>>>>> simply >>>>>>>>> can't promise that V2 will be implemented by then. When we get to >>>>>>>>> M94, I >>>>>>>>> think it is likely that we'll need to further extend the existing >>>>>>>>> origin >>>>>>>>> trial, but we should have a much better picture of the work required >>>>>>>>> by >>>>>>>>> then. Another possibility is that we ship all or part of the current >>>>>>>>> API to >>>>>>>>> general availability (if it is determined that the new changes are >>>>>>>>> additions, rather than changes, to the existing API). >>>>>>>>> >>>>>>>> >>>>>>>> Ideally, at that point you would have well-documented learnings >>>>>>>> from the OT that you could use to justify either a decision to ship >>>>>>>> some >>>>>>>> parts of the API, or change it towards a second OT. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Sorry if this is vague, but I am trying to keep our options open >>>>>>>>> and make sure that we aren't making promises we can't keep. My point >>>>>>>>> above >>>>>>>>> stands, that I don't want to set hard engineering deadlines which, if >>>>>>>>> we >>>>>>>>> don't meet them, will result in the disappearance of the API for our >>>>>>>>> customers. We are not trying to keep this API in origin trial >>>>>>>>> forever, but >>>>>>>>> we need time to work towards a solution. >>>>>>>>> >>>>>>>> >>>>>>>> The above SGTM! >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> On Mon, 10 May 2021 at 15:30, Yoav Weiss <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> In that case, we're talking about 6 milestones all in all? That >>>>>>>>>> sounds perfectly reasonable. >>>>>>>>>> >>>>>>>>>> On Mon, May 10, 2021 at 6:43 AM Glen Robertson < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry, I made a mistake in my original email in this thread: we >>>>>>>>>>> actually delayed the start of the OT so I had the milestones wrong. >>>>>>>>>>> Corrected milestones follow: >>>>>>>>>>> >>>>>>>>>>> *Experimental timeline* >>>>>>>>>>> - M88(Android)/M89(Desktop): First experiment milestone >>>>>>>>>>> - M90: Original final experiment milestone >>>>>>>>>>> - M93: Extended final experiment milestone >>>>>>>>>>> >>>>>>>>>>> On Fri, 7 May 2021 at 23:19, Aer Berkopec < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, May 7, 2021, 3:44 AM Yoav Weiss <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey Matt, >>>>>>>>>>>>> >>>>>>>>>>>>> The main goals for the duration restrictions that Alex >>>>>>>>>>>>> mentioned is to avoid cases where Origin Trials are being used as >>>>>>>>>>>>> a "soft >>>>>>>>>>>>> launch" mechanism and to avoid prematurely baking in the feature >>>>>>>>>>>>> into the >>>>>>>>>>>>> platform. >>>>>>>>>>>>> Significant changes to the API shape (as the ones you allude >>>>>>>>>>>>> to with the V2 API) would provide some assurances against bake >>>>>>>>>>>>> in, and from >>>>>>>>>>>>> my perspective would "restart the clock". >>>>>>>>>>>>> >>>>>>>>>>>>> However, that doesn't mean that breaking the API every X >>>>>>>>>>>>> milestones would enable y'all to have it in OT forevermore. We >>>>>>>>>>>>> also want to >>>>>>>>>>>>> see that the OT is being used to provide us with meaningful >>>>>>>>>>>>> feedback. I >>>>>>>>>>>>> believe that's the reason Alex asked for a summary of lessons >>>>>>>>>>>>> learned, as >>>>>>>>>>>>> well as a plan to eventually ship this. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, May 7, 2021 at 9:37 AM Matt Giuca <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the notes from your meeting. I think we can create >>>>>>>>>>>>>> a summary of the proposed design changes (however, note that >>>>>>>>>>>>>> it's somewhat >>>>>>>>>>>>>> undecided at this stage, what specific changes will need to be >>>>>>>>>>>>>> made). I >>>>>>>>>>>>>> don't want to block the extension of the origin trial on having >>>>>>>>>>>>>> a design >>>>>>>>>>>>>> proposal, since that could jeopardize customers' ability to use >>>>>>>>>>>>>> the API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does the 8-milestone run include the planned future "V2 API" >>>>>>>>>>>>>> origin trial, (i.e. if we run this for another 3 milestones, >>>>>>>>>>>>>> we'll only >>>>>>>>>>>>>> have 2 milestones left to do a V2 origin trial)? Or do you mean 8 >>>>>>>>>>>>>> milestones without making changes to the API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the latter would be pretty reasonable, but as I'm >>>>>>>>>>>>>> sure I've said before, I'm not too comfortable having a hard >>>>>>>>>>>>>> deadline on >>>>>>>>>>>>>> having to ship a new API or losing it. Having hard deadlines for >>>>>>>>>>>>>> shipping >>>>>>>>>>>>>> features, especially one this complex, generally results in >>>>>>>>>>>>>> rushed and >>>>>>>>>>>>>> buggy experiences. If we, say, get to M95 and have a working >>>>>>>>>>>>>> implementation >>>>>>>>>>>>>> for V2, but discover a bug at the last minute, I want to be able >>>>>>>>>>>>>> to have no >>>>>>>>>>>>>> hesitation to punt the release for an additional milestone (I >>>>>>>>>>>>>> don't want us >>>>>>>>>>>>>> to feel compelled to push it out the door because of an arbitrary >>>>>>>>>>>>>> 8-milestone limit). >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We definitely don't want you or other feature teams to rush to >>>>>>>>>>>>> ship features that are not ready. What I'd generally recommend is >>>>>>>>>>>>> for you >>>>>>>>>>>>> to have a rough plan for exiting the experimentation phase, and >>>>>>>>>>>>> to come >>>>>>>>>>>>> back to the API owners if e.g. last minute extensions are needed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I'll note that I raised this issue for this specific API in a >>>>>>>>>>>>>> general discussion with Blink API Owners in November 2020 ( >>>>>>>>>>>>>> email >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/_VsWsXMlezY/m/jTjGda60CwAJ>). >>>>>>>>>>>>>> Relevant quotes from myself from that email: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Until this work is done, we're not comfortable shipping this >>>>>>>>>>>>>>> API. We think backwards-incompatible changes may be required. >>>>>>>>>>>>>>> But we want >>>>>>>>>>>>>>> to get it into the hands of developers before then. An origin >>>>>>>>>>>>>>> trial lets us >>>>>>>>>>>>>>> do that, but it's got a soft time limit (3 milestones), after >>>>>>>>>>>>>>> which time >>>>>>>>>>>>>>> we'll have to apply for an extension. Maybe that's fine, >>>>>>>>>>>>>>> because we have >>>>>>>>>>>>>>> specific questions we'll still want answered. But it seems a >>>>>>>>>>>>>>> little unfit >>>>>>>>>>>>>>> for purpose, because we aren't using the OT to answer those >>>>>>>>>>>>>>> questions, >>>>>>>>>>>>>>> we're just extending it to keep things working while we do >>>>>>>>>>>>>>> design work >>>>>>>>>>>>>>> behind the scenes. >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> If API owners are happy with us ... repeatedly extending the >>>>>>>>>>>>>>> origin trial, without specific experimental questions, until we >>>>>>>>>>>>>>> have done >>>>>>>>>>>>>>> the internal research / spec work required to ship, then I >>>>>>>>>>>>>>> think we can do >>>>>>>>>>>>>>> without origin keys. My proposal was essentially an attempt to >>>>>>>>>>>>>>> formalize >>>>>>>>>>>>>>> that behaviour, rather than having to apply for all of these >>>>>>>>>>>>>>> exemptions and >>>>>>>>>>>>>>> extensions when they come up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now I didn't get a response to that email at the time. The >>>>>>>>>>>>>> context was that we were asking for a formal "origin keys >>>>>>>>>>>>>> <https://docs.google.com/document/d/1rQFoxVEOHBAYGz0DL0eSUur-DWN90o42OzFtEmcAO-Q/edit>" >>>>>>>>>>>>>> system, and in that meeting, I was told that it wouldn't be >>>>>>>>>>>>>> necessary >>>>>>>>>>>>>> because origin trials are suitable for that purpose. Per my >>>>>>>>>>>>>> final paragraph >>>>>>>>>>>>>> there, it *may* not be that origin trials are suitable for >>>>>>>>>>>>>> this purpose, if in practice API owners are going to block >>>>>>>>>>>>>> origin trial >>>>>>>>>>>>>> extensions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To be clear, we aren't intending to extend this indefinitely. >>>>>>>>>>>>>> I am hoping we can have this API shipped some time this year. >>>>>>>>>>>>>> But I am >>>>>>>>>>>>>> flagging that we can't guarantee that we'll have the necessary >>>>>>>>>>>>>> changes made >>>>>>>>>>>>>> by a specific milestone, and I don't want to be hard-bound to >>>>>>>>>>>>>> make those >>>>>>>>>>>>>> changes by a specific date. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, 7 May 2021 at 05:34, Alex Russell < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hey all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Met today at API OWNERS to discuss. I don't think folks are >>>>>>>>>>>>>>> *necessarily* opposed to extending this, but a few things >>>>>>>>>>>>>>> jump out: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - 8 milestones as at the far end of how long we'd like >>>>>>>>>>>>>>> any OT to run >>>>>>>>>>>>>>> - Given that, it would be helpful to summarize both a >>>>>>>>>>>>>>> plan for what the new API will look like as well as lessons >>>>>>>>>>>>>>> learned to date >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I know that some of that is captured in the DGAPI bugs >>>>>>>>>>>>>>> linked, but it would help if there were a summary document that >>>>>>>>>>>>>>> described >>>>>>>>>>>>>>> the developer feedback to date, the changes you'll be making to >>>>>>>>>>>>>>> the API to >>>>>>>>>>>>>>> compensate, and the plan for (hopefully) validating the new API >>>>>>>>>>>>>>> works as >>>>>>>>>>>>>>> developers expect quickly, then launching or sunsetting. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thursday, May 6, 2021 at 8:30:38 AM UTC-7 Glen Robertson >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [email protected], [email protected], >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/WICG/digital-goods/blob/master/explainer.md >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/WICG/digital-goods/blob/master/explainer.md >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An API for querying and managing digital products to >>>>>>>>>>>>>>>> facilitate in-app purchases from web applications, in >>>>>>>>>>>>>>>> conjunction with the >>>>>>>>>>>>>>>> Payment Request API (which is used to make the actual >>>>>>>>>>>>>>>> purchases). The API >>>>>>>>>>>>>>>> would be linked to a digital distribution service connected to >>>>>>>>>>>>>>>> via the user >>>>>>>>>>>>>>>> agent. In Chromium, this is specifically a web API wrapper >>>>>>>>>>>>>>>> around the >>>>>>>>>>>>>>>> Android Play Billing API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink>Payments >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Search tags >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> payments <https://chromestatus.com/features#tags:payments>, >>>>>>>>>>>>>>>> billing <https://chromestatus.com/features#tags:billing> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/571 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In progress >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Similar to Payment Request: this API is used to talk to >>>>>>>>>>>>>>>> specific store backends, and so its usage is tailored to the >>>>>>>>>>>>>>>> specific >>>>>>>>>>>>>>>> store. The reason it's a proposed web standard is so that the >>>>>>>>>>>>>>>> same code >>>>>>>>>>>>>>>> (which is specific to one store) is portable across browsers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gecko: No signal ( >>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/349). >>>>>>>>>>>>>>>> Awaiting feedback. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebKit: No signal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Web developers: Positive ( >>>>>>>>>>>>>>>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350 >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Used in tandem with the Payment Request API. >>>>>>>>>>>>>>>> Goals for experimentation >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - General API design. Determine whether developers need to >>>>>>>>>>>>>>>> access more data that would be exposed through the Play >>>>>>>>>>>>>>>> Billing API but is >>>>>>>>>>>>>>>> not exposed through our web API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Specifically, we would like to know whether the API is >>>>>>>>>>>>>>>> suitable for abstracting over other non-Play stores. While >>>>>>>>>>>>>>>> running an >>>>>>>>>>>>>>>> experiment with the current implementation won't tell us this, >>>>>>>>>>>>>>>> it will set >>>>>>>>>>>>>>>> up real-world clients and we can then try their sites on other >>>>>>>>>>>>>>>> implementations. >>>>>>>>>>>>>>>> Experimental timeline >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - M87 (2020-11-17): Experiment begins >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - M90 (2021-04-13): Original experiment end date >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - M93 (2021-08-31): Extended experiment end date >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Reason this experiment is being extended >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An origin trial ran from M87 to M90 and found some areas of >>>>>>>>>>>>>>>> developer friction and new features needed (see bugs >>>>>>>>>>>>>>>> labeled DGAPI >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=label%3ADGAPI>). >>>>>>>>>>>>>>>> We haven't yet had time to fix all the issues and update the >>>>>>>>>>>>>>>> API. We are >>>>>>>>>>>>>>>> planning to update the API and run a next phase of the >>>>>>>>>>>>>>>> experiment with a v2 >>>>>>>>>>>>>>>> API soon. We would like to avoid stopping the experiment in >>>>>>>>>>>>>>>> between the >>>>>>>>>>>>>>>> phases to avoid unnecessarily disrupting current users of the >>>>>>>>>>>>>>>> API while we >>>>>>>>>>>>>>>> work on the next iteration. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ongoing technical constraints >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No, Android and Chrome OS only (the two platforms where we >>>>>>>>>>>>>>>> have Play Store integration). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://crbug.com/1061503 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://crbug.com/1017947 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- -mike -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcnMZ%2Brc_HuKx8fhs0RVc94fmhUacaneftCcM%2BjxOGk9g%40mail.gmail.com.
