- From: Domenic Denicola <d@domenic.me>
- Date: Mon, 10 Nov 2014 23:14:29 +0000
- To: Dimitri Glazkov <dglazkov@google.com>, Anne van Kesteren <annevk@annevk.nl>
- CC: Mounir Lamouri <mounir@lamouri.fr>, WebApps WG <public-webapps@w3.org>
From: Dimitri Glazkov [mailto:dglazkov@google.com] >> It's still not clear to me what the advantage is of creating a framework for designing proprietary APIs. > > If we don't do something like this as a platform, we'd be always lagging behind. Many new ideas start as proprietary. It takes time for these ideas to take shape and travel toward larger acceptance -- or die. Can you help us understand the advantages of a string-based proprietary APIs over a functions-and-objects proprietary APIs? We've had the latter for many years with vendor prefixes, so what are the advantages of putting them behind navigator.connect? navigator.connect seems great just for talking to foreign service workers (in fact it can be the basis for a very general and powerful intents system). But from what I can understand it's serving two masters: talking to service workers built on standards that run in any browser, and also talking to virtual "service workers" that implement proprietary string-based APIs using "URLs" that only work in certain browsers. I don't understand how these are connected... Hope you can help me out there :)
Received on Monday, 10 November 2014 23:15:01 UTC