Re: Review of Payment Apps Proposal

On 4/21/16 15:14, Shane McCarron wrote:
>
>
> On Thu, Apr 21, 2016 at 2:50 PM, Adrian Bateman 
> <adrianba@microsoft.com <mailto: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