Re: Core API Proposal

Just a short return on the native extension thing.

IMO, it should not be mixed with in-browser extensions, it is really an entirely different topic.

Anders

On 2016-05-03 07:29, Florian Rivoal wrote:
>
>> On May 3, 2016, at 12:25, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>
> Hi,
>
>> IMO, the value of standardized browser-based extensions becomes fairly limited if you don't reach a level of compliance where you can use a common "App Store".
>
> Whether or not the various browser vendors allow installing from sources other than their own app store is for them to decide (although I would strongly encourage them to do so), but yes, making sure that this is technically feasible is absolutely something we should aim for. This means that we will not only need to standardize the APIs and events, but also the manifest and packaging. Which is part of what Mike is proposing, so we're good so far.
>
>> However, there's a rather unarticulated (but easy to verify) need for a replacement
>> of the deprecated ActiveX and NPAPI schemes.  Chrome (desktop) supports such a thing:
>> http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/
>>
>> FWIW, I have taken the liberty of enhancing this system (without touching Chrome):
>> https://github.com/cyberphone/web2native-bridge
>>
>> Implementing Google's solution "as is" would IMO be serious mistake. A workaround
>> should not transcend into a standard:
>> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
>
> Communication with native processes is indeed an important feature, and I agree that we should look at, but not necessarily copy, what google has been doing in this area, and compare that with alternative approaches.
>
> I suspect that the first iteration of a specification for extensions might skip this feature, and first focus on standardizing the core parts before turning to this kind of more complex (and probably more controversial, since there are several possible approaches) features.
>
> However, if people want to work on it from early on, I am certainly not going to stand in the way.
>
> It also depends on when browser vendors expect to be shipping this. The sooner they do, the earlier we should work on it.
>
> What do others think? Is this a topic to be explored ASAP, or to be deferred until we have stabilized the basics?
>
>  - Florian
>

Received on Tuesday, 3 May 2016 05:36:28 UTC