- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 17 Sep 2015 06:16:26 +0200
- To: Marijn Kruisselbrink <mek@chromium.org>
- Cc: Alex Russell <slightlyoff@google.com>, "www-tag@w3.org List" <www-tag@w3.org>, Jungkee Song <jungkee.song@samsung.com>
On 2015-09-16 20:55, Marijn Kruisselbrink wrote: > what you're asking for is not really the client side API for this, > but some standardized (hopefully cross browser) way to implement > the native side of this. Maybe some standardized way a native application > could register itself with a webbrowser to handle certain actions from websites? > I know various people have been thinking about this problem space, although I'm > not quite sure what the current status of that is. And there have of course been > various attempts in the past. Actually standardizing something of how a browser > interacts with the native operating system is of course complicated. > I'm not quite convinced yet that it is something that makes sense to do, > although it certainly seems like an area worth exploring. You don't have to go particularly far to find a "customer" :-) https://www.android.com/pay/ A Wallet that doesn't work on the Web is simply put "lame", isn't it? AFAIK our friends in Cupertino have a similar problem... When it comes to technical solutions I would be a bit cautious about overloading APIs like foreign-fetch because the requirements seem pretty different for invoking and communicating with local applications, and for accessing remote Web resources. The idea is not creating a "workaround" like Chrome's Native Messaging, but making [specially crafted] native "Apps" first class citizens on the Web. Cheers, Anders R https://github.com/cyberphone/web2native-bridge#wallet-application
Received on Thursday, 17 September 2015 04:17:06 UTC