IcedTea-Web and FireBreath Plugin API

[Mattias Eliasson]

2014-06-19 17:26, Andrew Azores skrev:
> On 06/19/2014 11:21 AM, Mattias Eliasson wrote:
>> Hi,
>>
>> I also would suggest making a generic java libraries for making Java plugins, for example a JFireBreath API if you chose to use FireBreath as a base. Also it would be useful to design such a library so that plugins can be hosted by Java-based browsers. Javafx WebEngine for example do not support plugins currently, and extending it to support NPAPI would bring to many layers where things can go wrong. Making a clean separation of the NPAPI part of icedtea-web and the Java part would allow for WebEngine and other Java browsers to host Applets without involving a native layer.
>>
>> Generically I can see that IcedTea-web contains a lot of code that would be better of if its made into separate libraries. For example sandboxing are surely interesting in other projects. I found a sandboxing library but it seams to be dead.
>>
>> 2014-06-12 16:20, Andrew Azores skrev:
>>> On 06/11/2014 08:45 PM, Mattias Eliasson wrote:
>>>> Hi,
>>>>
>>>> As IcedTea-web have a architectural simplification task I am curious if you have looked at the FireBreath plugin API? It seams to provide nice high level C++ API for both NPAPI and IE ActiveX. That should help reduce IcedTea-Web code a lot since NPAPI are quite chatty and hopefully make it easier to squash remaining NPAPI-related bugs.
>>>
>>> I haven't looked into this myself before, but it looks interesting. We'll see what others think about the idea and perhaps look into porting over. Thanks for proposing it.
>>>
>>> Thanks,
>>>
>>
>
> (CC'ing the distro-pkg-dev list)
>
> The sandboxing in IcedTea-Web is mostly just a wrapper around the sandboxing provided by the JVM itself. All IcedTea-Web does with it is use this "primitive" to create a sandboxing context for applets in particular. In all honesty, this context really boils down to a Map and a bunch of Java-applet-specific logic on deciding how to populate this map.
>
> As for the FireBreath API stuff... I can't really comment on it. I just don't know enough about browser plugin development in particular. What you're proposing sounds to me like it would be adding extra APIs that IcedTea-Web would expose without a mirror in the proprietary plugin, however, which would severely limit the user base I'd think.
>
> Thanks,
>
I consider the Java sandboxing API to be quite chatty which makes it a candidate for a lib, but that's really a side-issue here.

I have done a lot of research on browser plugin development for a number of reasons. Java plugins (both proprietary and FOSS) are notoriously unstable. The Flash plugin are a bit more stable but they also have a lot more resources allocated to this. The proprietary plugin are as far as I know based on NPAPI and the ActiveX API for IE. Using FireBreath would simply be a replacement of both with something that provides a similar API but both have the advantage of being a multi-API abstraction layer and provide a clean high-level C++ interface. Both NPAPI and ActiveX are quite chatty API:s which are my main point here. Using FireBreath would remove a lot of boilerplate code from IcedTea-Web that are not specific to this plugin, but needed in most plugins.

Another argument are that NPAPI are being phased out. Chrome have dropped it, Firefox are planning to and Flash have dropped it at least for Linux. It's a bit unclear how to migrate 3:d party plugins to a post-NPAPI world, but my point are that such a migration should concern a shared component such as FireBreath and not individual plugins such as IcedTea-Web.

And finally as long as NPAPI are still around there are a lot of problems around it. It's chatty and complex, and if that ain't enough there are a lot of difference between browser implementation. I know that both the proprietary and the open plugin have had their fair share of problems with this. So have have the FireBreath developers. Assuming that a lot of those problems are not specific to Java Applets, it makes sense to share the burden of figuring them out with other projects. This are true for most abstraction layers, but as NPAPI are quite notorious it becomes a more central issue then it otherwise would be.