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>
Cc:
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:
https://github.com/w3c/webpayments/issues/130#issuecomment-220319159
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