> 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?
"Benjamin Smedberg" <benj...@smedbergs.us> wrote in message news:firstname.lastname@example.org... > 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 >