IcedTea-Web and FireBreath Plugin API

[Jacob Wisor]

On 06/25/2014 03:37 AM, Mattias Eliasson wrote:
> 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.

All of this may be true but the main question or problem with the FireBreath API 
I would raise here is that it adds another dependency on a library which really 
is not absolutely necessary to IcedTea-Web. The benefits it may offer to 
IcedTea-Web are just too little in contrast to the complexity every dependency 
adds, like updating, code support, etc.

Besides, every layer of abstraction loses information and semantics of the lower 
layer to some degree. The fact that FireBreath tries to tie up two absolutely 
different API concepts makes things even more complicated. Well, maybe other 
plugins do benefit a lot from FireBreath but I am really not convinced that 
FireBreath would be that much of a benefit to IcedTea-Web, which actually is not 
that complicated.

Jacob

p.s.: Yes, ActiveX is even more chatty than NPAPI but there are a few good 
reasons for this, and another few to keep it that way.