- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 6 Jul 2016 19:00:30 +0200
- To: Adam Roach <abr@mozilla.com>, "Michael[tm] Smith" <mike@w3.org>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>, Florian Rivoal <florian@rivoal.net>
On 2016-07-06 18:04, Adam Roach wrote: > On 7/6/16 00:19, Anders Rundgren wrote: >> Although constraining native applications to the Web Payment API may be simpler (?), >> I wouldn't take that path. > > Are you proposing that merchant websites would use one kind of API to use web-based > payment apps, and a completely different one for native payment apps? Well, that wasn't the intent at least. I'm rather proposing that there should be a standardized method for interacting with native apps, be it from the Web Payment API or elsewhere. > That seems profoundly inelegant. Merchant sites shouldn't have to worry about the > underlying technology being used to provide payments to them any more than is necessary. Agree 100%. > >> Below is a enhanced variant of native messaging which is "liberated" from >> the generic browser extension scheme... > > This approach raises a number of issues that I suspect will either be showstoppers, > or take a fairly long time to unwind. There has been a concerted push to wind down > content-available bridge technologies, like NPAPI, and I doubt that introduction of > a new one at this point would be received with much enthusiasm. Unlike NPAPI or ActiveX which executes inside of the browser, this proposal does approximately what Android's intent system already does (starts a named external application), but with a twist; It can "talk" as well. Anders Rundgren > > -- > Adam Roach > Principal Platform Engineer > Office of the CTO
Received on Wednesday, 6 July 2016 17:01:08 UTC