Hi Blink Owners, We have now implemented DGAPI v2.0 which is in M96 as a separate OT. The DGAPI v1 code has been removed in M96 so the v1 trial will not be exposed to versions greater than M95.
However, the OT system is based around dates instead of milestones, and the v1 OT is currently set to end on 2021-12-14, two weeks after M96 hits stable. At that point we expect a large percentage of CrOS users to still be on M95 (or lower), with that percentage decreasing asymptotically over the following weeks. As previously discussed, we would strongly like to avoid dropping support for users in between the origin trials and launch. Would it be possible to extend the end date of this v1 API trial (for M95 and below only) to allow more time for users to update to M96 before the API is cut off? Two months total would allow time for the majority of users to update (2022-01-30). Web developers wishing to use DGAPI are already required to update their code to support the new version in M96, so there is no risk of burn-in of the v1 API. Thanks for considering, -Glen On Fri, 10 Sept 2021 at 06:25, Mike West <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcnMZ%2Brc_HuKx8fhs0RVc94fmhUacaneftCcM%2BjxOGk9g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPV%2BSg-er1aE1pvYnG1OVai6J7_RN1haYXTHN%2BV7TpF2bQ3hsg%40mail.gmail.com.
