- From: Brendan Eich <brendan@secure.meer.net>
- Date: Mon, 10 Nov 2014 20:33:33 -0500
- To: Domenic Denicola <d@domenic.me>
- CC: Dimitri Glazkov <dglazkov@google.com>, Anne van Kesteren <annevk@annevk.nl>, Mounir Lamouri <mounir@lamouri.fr>, WebApps WG <public-webapps@w3.org>
Right. Didn't we have a problem with Canvas's string-based getContext already? http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html /be > Domenic Denicola <mailto:d@domenic.me> > November 10, 2014 at 6:14 PM > From: Dimitri Glazkov [mailto:dglazkov@google.com] > > > 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 :) > > Dimitri Glazkov <mailto:dglazkov@google.com> > November 10, 2014 at 12:45 PM > On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren <annevk@annevk.nl > <mailto:annevk@annevk.nl>> wrote: > > On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov > <dglazkov@google.com <mailto:dglazkov@google.com>> wrote: > > FWIW, I think we should be concentrating on something like the > Tubes (aka > > navigator.connect): https://github.com/dglazkov/tubes > > > > It is hard to impossible to get these types APIs right on the > first try. > > That's why we need to create a clearinghouse for capability > experiments and > > be data-driven in designing the right API. > > 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. Instead of shunning these ideas until they mature -- and thus > effectively shut the door to any innovation, we should embrace them > and give them a place in the platform. > > Take > http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-overview.html > as an example. It's unclear whether this will lead to anything great. > It's even less clear what the Web platform API should look like, or > whether this will every result on a standard API. However, if we wait > until clarity, we as a platform would lose the ability to participate > in the virtuous innovation cycle and, as a result, lose more developer > mindshare. > > FWIW, it is perfectly reasonable for us to admit that we as a platform > aim to always be years behind other platforms. But then we should make > this clear and communicate it to developers who keep trying to not > give up on the Web as a viable modern development platform. > > :DG< > > > > -- > https://annevankesteren.nl/ > > > Anne van Kesteren <mailto:annevk@annevk.nl> > November 10, 2014 at 4:38 AM > > It's still not clear to me what the advantage is of creating a > framework for designing proprietary APIs. > > > Dimitri Glazkov <mailto:dglazkov@google.com> > November 7, 2014 at 1:01 PM > FWIW, I think we should be concentrating on something like the Tubes > (aka navigator.connect): https://github.com/dglazkov/tubes > > It is hard to impossible to get these types APIs right on the first > try. That's why we need to create a clearinghouse for capability > experiments and be data-driven in designing the right API. > > :DG< > > > Mounir Lamouri <mailto:mounir@lamouri.fr> > November 7, 2014 at 11:57 AM > (I realise that my reply went to public-webapps instead of whatwg, not > sure why. I will blame my email client :)) > > On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote: >>> Wouldn't be worth experimenting first with a list of predefined share >>> endpoints (that you anyway might want to have) and see if the feature is >>> actually something that users are looking for? >> We have something like that in Firefox Nightly. Apple ships something >> similar in Safari. Both can be extended through proprietary APIs. > > I think it would be great if Mozilla could keep track of the usage of > this feature and share that data. > >>> Furthermore, wouldn't >>> that make sense to have a similar mechanism than Open Search and have a >>> way for a website to advertise its share endpoint(s)? Maybe the Manifest >>> could be a good use for that. Generally speaking, I see a lot of common >>> aspects between Open Search and this proposal. >> Maybe. It would be even less flexible and depend even more on user >> interface innovation from the user agent. > > I don't think the issue here is flexibility. It's extensibility. You > want website to be able to advertise themselves in that list. Thus, > websites will only try to do so if they see a benefit in doing that, in > other words, if that feature is actually used by Firefox users. > > As a side note, I don't think that innovation always need to come from > new APIs. That feature sounds like a great opportunity to innovate > within the browser UI then iterate with an API. > > -- Mounir >
Received on Tuesday, 11 November 2014 01:34:15 UTC