- From: Marijn Kruisselbrink <mek@chromium.org>
- Date: Wed, 16 Sep 2015 11:55:45 -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+OSsVaFuRpMb06ab-Azmv3pXQXLJP3QBFy7hO7HDfrnYZ4MHg@mail.gmail.com>
On Wed, Sep 16, 2015 at 12:55 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2015-09-15 06:49, Marijn Kruisselbrink wrote: > >> >> >> On Mon, Sep 14, 2015 at 9:41 PM, Anders Rundgren < >> anders.rundgren.net@gmail.com <mailto: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. > > That was brief indeed :) > > May I as a hands-on guy ask a few questions while we are waiting for a > more elaborate specification? > Is foreign-fetch (among many things) supposed to replace Native Messaging > by offering similar (hopefully much better...) functionality? > > If so, is this a standardization effort performed by the WHATWG? > Currently foreign fetch is really just meant as a communication mechanism between service workers, possible across origins (and a way for service workers to transparently provide offline capable services to other websites). I don't think there really are any plans to come up with a standardized way to extend this to services provided by anything other than service workers. But then the client side API of foreign fetch is just the same fetch API that already exists (maybe with an extra flag to indicate the request should not fall back to the network if no service worker is available), so I don't see a reason individual browsers couldn't map some URLs to native services. Something like that is already being done anyway these days, with about:, chrome://, chrome-extension:// urls etc that are all being handled "offline" by code that isn't web content. Of course 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. > > Anders > > > >> 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 protocol 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> >> <mailto: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>> <mailto: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 Wednesday, 16 September 2015 18:56:14 UTC