La tôi
Đã gửi từ iPad của tôi Ngày 27-08-2021, vào lúc 11:56, Glen Robertson <[email protected]> viết: > 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 (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 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). >>>>>>>>>>>> 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" 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Search tags >>>>>>>>>>>>>> payments, 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). 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? >>>>>>>>>>>>>> No >>>>>>>>>>>>>> >>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>> https://crbug.com/1061503 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>> https://crbug.com/1017947 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>> https://chromestatus.com/feature/5339955595313152 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs >>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ >>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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/CAHqYdcYbiwZYA6atQ%3DsN6nkaT6M-7avGhOBdwjA373PG%3DCq2cg%40mail.gmail.com. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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/CAL5BFfW657p0WOQSZeJtJdNz%2Bo5EYdy8q7uJDfb%3D05MUXtLLSg%40mail.gmail.com. >>> >>> -- >>> 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_pU3Q59ZcBVDyY-TFDmhUjW_3e6wqPRfWLZDqJER_r4Q%40mail.gmail.com. > > -- > 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-%2BDqTw0coyVgjHLF4nytoDMDAyTBGv4woppiuyEOwwew%40mail.gmail.com. -- 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/EBD0C095-66F8-4381-A05C-BF9B97C4D9E7%40gmail.com.
