Thanks! On Fri, 29 Oct 2021 at 16:41, Chris Harrelson <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_dPo2bg7zVyobKN9TO2hLgpq1KW5AS-yfdW1b9ObU7Xw%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%2BSg90gEggPQmPckZYd3e-ZooDoiTzpm%3DsFLiQrbWdtK0o8g%40mail.gmail.com.
