- From: Marijn Kruisselbrink <mek@chromium.org>
- Date: Mon, 14 Sep 2015 21:49:12 -0700
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Alex Russell <slightlyoff@google.com>, "www-tag@w3.org List" <www-tag@w3.org>, Jungkee Song <jungkee.song@samsung.com>
- Message-ID: <CA+OSsVYt7_yHh0Wk_phB=e=TAP7XmpLRgpTkw5rHZDXtiEWn5w@mail.gmail.com>
On Mon, Sep 14, 2015 at 9:41 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2015-09-14 15:51, Alex Russell wrote: > >> The navigator.connect() effort died at the last Service Worker >> Face-to-Face, but foreign-fetch (as I outlined it here) is the logical >> replacement. >> > > I didn't find much concrete information, is there a write-up somewhere? > Foreign fetch is briefly described at https://wiki.whatwg.org/wiki/Foreign_Fetch and https://gist.github.com/mkruisselbrink/f6957bece64740926b84. And I started turning it into an actual pull request for the service worker spec, but haven't actually uploaded any of that yet. > Anyway, if this is for real, it should be a separate effort, preferably > run as a W3C WG since it > would effectively be a replacement for the proprietary (and now > deprecated) browser "plugins", > "localhost" services, and custom proocol handlers which are currently used > to enhance the web. > There's a huge existing and potential customer-base out there! > > Anders > > >> On Mon, Sep 14, 2015 at 1:07 AM, Anders Rundgren < >> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> >> wrote: >> >> On 2015-09-12 00:32, Alex Russell wrote: >> >> I don't think you need a new API here; you can use existing >> origins and foreign-fetch to do most of these interactions: >> https://github.com/slightlyoff/ServiceWorker/issues/684 >> >> The idea would be to map a native API to a URL and have a fetch >> to it invoke the method. >> >> >> >> https://mkruisselbrink.github.io/navigator-connect/use-cases.html#extension >> >> >> >> On Thu, Sep 10, 2015 at 10:39 PM, Anders Rundgren < >> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> >> <mailto:anders.rundgren.net@gmail.com <mailto: >> anders.rundgren.net@gmail.com>>> wrote: >> >> This project have now transcended from "slideware" to >> proof-of-concept emulator. >> API: https://github.com/cyberphone/web2native-bridge#api >> >> To spice it up a bit, I've created two sample applications, >> one which shows the >> basic communication, and another which implements a local >> "wallet" which can be >> tested against a public merchant- and bank-server on the >> Internet. >> >> For those who feel that schemes like this leads to a closed >> Web, you can relax, >> the system and samples already run on desktop versions of >> Windows, OS/X, and Linux. >> >> Regarding browser support: Mozilla recently announced that >> they intend to >> implement the underpinning Chrome Native Messaging system. >> >> >> On 2015-04-28 08:22, Anders Rundgren wrote: >> >> Dear Web Architects, >> >> As you all know the "App" phenomena has after the >> introduction of iPhone and Android become at least as popular as the Web. >> >> There's also a bunch of applications that so far haven't >> made it to Web like Secure/Convenient/Decentralized payments. Given the >> fact that the latter has been "on the radar" for 20 years, I think we can >> safely conclude that it won't happen either. >> >> With this posting I would like to challenge the current >> thinking (very slowly DUPLICATING the functionality of the "App" world into >> the Web), by proposing an OPTION enabling developers to rather COMBINE the >> power of both worlds: >> >> https://lists.w3.org/Archives/Public/public-web-security/2015Apr/0012.html >> >> A notable side-effect of this proposal is that enables >> Web innovation by third-parties who currently often have no viable >> alternative to "App"-only solutions. >> >> In a somewhat more market-oriented way: Revitalizing the >> Web. >> >> Sincerely, >> Anders Rundgren >> >> >> >> >> >> >> >> >
Received on Tuesday, 15 September 2015 13:05:39 UTC