I think it's fine to extend the date of the v1 API OT, targeted only at M95 and below. LGTM for that!
On Thu, Oct 28, 2021 at 11:40 PM Glen Robertson <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg-er1aE1pvYnG1OVai6J7_RN1haYXTHN%2BV7TpF2bQ3hsg%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/CAOMQ%2Bw_dPo2bg7zVyobKN9TO2hLgpq1KW5AS-yfdW1b9ObU7Xw%40mail.gmail.com.
