Re: Minutes [Was: [Agenda] 7 Feb 2017 Payment Apps task force call]

On February 8, 2017 at 4:56:06 AM, Ian Jacobs (ij@w3.org) wrote:
> > * Issue 99: The consensus on the call was that, while people would
> support reuse of
> objects, we think the way they are currently structured in PR
> API means they do not
> lend themselves to reuse in the context of payment apps. This
> is both because there
> would be a lot of empty fields when shipped to the payment app,
> and also there is
> some data from the user agent that should not be exposed on the
> merchant side.
> While PR API could change to enable a more reusable structure,
> the sentiment from
> developers on the call was that that would be unlikely to happen.
> AdrianHB took an action to summarize the discussion online for
> further discussion
> with Marcos, to see if there are other ways to support reuse.

I'm willing to compromise on those - but they need to be good proxies
for PaymentResponse and PaymentRequest (they should look and feel much
the same as those in the PR API - again: I don't want to end up with
two very different APIs in Gecko and what we expose to developers -
they should be as close as humanly possible).

The current set of things in the spec need some love to get them
working correctly with the PR API.

As I said in another email - we, as a group, need to see and write
code that shows:

 * Getting permission
 * adding, removing, updating, payment methods
 * handling .canMakePayment(),
 * handling POSTing for payment (without a secure window).
 * Getting the browser to open a secure window
 * handling PaymentRequest .abort(), .updateWith(), and whatever else
PaymentRequest can throw at us.
 * creating a PaymentResponse - and showing how it coordinates between
the secure window and merchant.
 * Other critical things that I can't think of right now... Please add them!!!

I would like us to avoid having long winded discussions about the
above and really just focus on showing how it works  with code. Can
someone please work with me on the above? We should just create a
simple markdown file somewhere to show how each would be addressed
... no spec text, no formalities, etc.  Just code... proof is in the
pudding and all that. I've proposed and showed solutions already for
some of the above in my proposal. We can take that as a starting point
and modify it a bit.

Kind regards,
Marcos

Received on Wednesday, 8 February 2017 11:56:32 UTC