Re: The future of binary embedding

Hi Benjamin,

> As a project, we aren't going to spend effort trying to solve the problems 
> associated with in-process embedding.

Can you clarify what this means?  Is it just referring to the dropping of 
gtkmozembed/javaxpcom/ActiveX control?  Or is it saying that once mozilla 
has entered the multi-process world that in-process embedding like can 
currently be done via typical XPCOM will no longer be possible?

Thanks,
Grant


"Benjamin Smedberg" <[email protected]> wrote in message 
news:[email protected]...
> Last summer, I led a session at the Mozilla summit to discuss whether and 
> how we ought to continue supporting our various embedding efforts 
> (gtkmozembed, javaxpcom, the ActiveX control, the NSView embedding widget, 
> etc) given the effort involved in preserving their various degrees of code 
> and binary compatibility with Mozilla core. We came the following 
> conclusions:
>
>    * Embedding Mozilla rendering into other processes is a tough
>      problem. We never solved it fully, and each embedder has had to
>      spend lots of time tweaking things.
>    * Firefox is the key product of the Mozilla project; to the extent
>      that supporting embedding takes away from Firefox, we should
>      strongly prioritize Firefox.
>    * Binary compatibility of our embedding bindings is a high cost
>      which is not worth the benefits.
>    * As we move Firefox into a multiple-process model, the embedding
>      solution we really want is very different from the one we
>      currently have: we really want embedders to be simple containers
>      for a separate Firefox process which would do the actual web
>      rendering.
>
> Because of this, I'm planning on making the following changes in our code:
>
>    * Remove gtkmozembed and its supporting code. The promise of
>      gtkmozembed was a binary-compatible wrapper that GTK applications
>      could use to easily get web rendering into their application.
>      Without significant supporting code to deal with profiles,
>      certificates, prompts, and other details, this code doesn't work
>      correctly, and is unmaintained.
>    * Remove javaxpcom and its supporting code.
>    * Remove the ActiveX control and plugin, and the IDispatch code
>      which was created to support interconnecting the ActiveX code with
>      our DOM.
>
> Various people have expressed interest in taking of maintenance of these 
> embedding solutions, but I lost their email addresses in a recent computer 
> crash. Anyone with interest should please email me, and I will happily 
> work with you to set up a Mozilla repository for the continued maintenance 
> of these projects.
>
> As a project, we aren't going to spend effort trying to solve the problems 
> associated with in-process embedding. Once separate-process rendering is 
> implemented in Firefox, we may consider ways to make really simple 
> multi-process embedding a possibility. If you are interested in helping to 
> begin implementation of this multiprocess embedding solution, please let 
> me know, and I will help guide you in the right direction.
>
> --BDS
> Module Owner, Embedding
>