I don't think I understand how browsers can be prevented from allowing payment without supporting registration? On 22 April 2016 at 01:42, Adam Roach <abr@mozilla.com> wrote: > On 4/21/16 15:14, Shane McCarron wrote: > > > > On Thu, Apr 21, 2016 at 2:50 PM, Adrian Bateman < <adrianba@microsoft.com> > adrianba@microsoft.com> wrote: > >> >> No, in fact I've argued for the opposite. It's entirely reasonable for us >> to develop v2 of a registration API without having to go back and change >> a dependency in the Payment Request API. They should be independent so >> that they can proceed independently. > > > Huh? I really don't understand. Payment App registration is a > fundamental requirement of this ecosystem. The browser payment request API > would have nothing to communicate with if there are no payment apps > registered. Certainly the test environment (as I am designing it) > registers a payment app with the implementation under test so that we can > process messages from and to the user agent just as we will model those > messages from the "payee". A normative reference in a W3C spec says "this > spec requires that this other spec be in the environment too, as it DEPENDS > upon this other spec". Surely you are not proposing that we push out a > version of the browser payment api that does not require support for > payment app registration? > > > I'm still coming up to speed on the specifics of the existing proposals; > however, with the high-level understanding of the basic purpose of the > payment functions and the registration functions that I do have, I find > proposals not to make the payment functions strictly dependent on the > registration functions troublesome. > > I'll reiterate the point that Manu has made: the only way unlinking these > makes sense is in a world where we envision some implementations that do > one without the other. Allowing registration without payment is clearly > nonsense; and allowing payment without registration implies that we're > going out of our way to accommodate browsers with non-extensible, baked-in > payment providers. > > And that would be very bad for users. > > -- > Adam Roach > Principal Platform Engineer > Office of the CTO, Mozilla >Received on Friday, 22 April 2016 16:17:08 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:16 UTC