W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: [w3c/webpayments] Letting the payment app decide between HTTP and Javascript communication (#130)

From: Adrian Hope-Bailie <notifications@github.com>
Date: Thu, 19 May 2016 06:10:22 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/130/220319159@github.com>
> The WebRTC IdP registration isn't persistent -- it's added to each RTCPeerConection object after it's created. So it's not exactly the model to look at. When I mentioned it as a potential model for the local portion of payment apps, I meant it more as a model for the communication channels.

That's true but it's a nice way for an "app" to install a piece of executable Javascript that can be run by the browser when required. I have an idea of how we could do something similar will try and put a PR together.

> So, if we're going down the POST path, I would suggest we contemplate using POST for all interactions, and describe how to use service workers to process such requests locally.

I agree with this and only propose the JavaScript option as an addition. It never hurts to give developers choices.

In that respect, I think #131 is a more extreme change than we need. I don't think we should take out the existing behaviour but rather add other behaviour if the app chooses to use Javascript.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Received on Thursday, 19 May 2016 13:10:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 May 2016 13:10:53 UTC