Re: The future of binary embedding
cee alf
Thank you for your relay kindly.
2011/3/29 Benjamin Smedberg <benj...@smedbergs.us>
> 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
>
> _______________________________________________
> dev-embedding mailing list
> dev-em...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-embedding
>
Glen Gray
Unlike some of the other posters, I do use GtkMozEmbed in as a fullscreen UI on a kiosk/embedded-pc. We managed to get everything working with xulrunner 1.9.2 after some serious focus bugs where addressed.
I'll need to know what my options are going forward and how we will be able to control the browsers functionality (custom uri's trigger application launching, restricted access to uri's based on users credits etc.).
Do I focus on using a swapping out GtkMozEmbed for a webkit browser or come up with something different.
What is the current status as regards xulrunner 2.0 ?
--
Glen Gray
<sla...@slaine.org>
Antonio Gomes
this point?
--
--Antonio Gomes
Asa Dotzler
> The question is: does mozilla care about stuff other than their products at
> this point?
No, that is not the question. There is no question about "caring" here
and it's both rude an insulting to phrase it that way.
Re-read what Benjamin wrote. The issue is resources. Mozilla is a large
community of people but right now there are a shortage of people with
both the time and the knowledge to keep some of these capabilities going.
There is no free lunch and never has been.
Benjamin closed his update with a for help that could build some of
these capabilities into the future of the Mozilla platform. If you, as
part of the Mozilla community, are or can find those resources, then
stand up and say so. If you're not, find a better way to address your
frustration than insulting Mozillians who are giving way more than
anyone should rightly expect of them to keep the most important parts of
the project moving forward.
- A
Antonio Gomes
> _______________________________________________
> dev-embedding mailing list
> dev-em...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-embedding
>
--
--Antonio Gomes
Ami Ganguli
> No, that is not the question. There is no question about "caring" here and
> it's both rude an insulting to phrase it that way.
I think it's a legitimate question. Maybe the thing is to phrase it
differently:
"is embedding by third parties considered strategic enough to
Mozilla's mission for it to invest its limited resources in it?"
I've wanted to use Gecko for embedding various times and ended up
having to give up due to my own time constraints. There always ends
up being some barrier to making it work that would take more time to
solve than whatever project I'm working on will allow.
I'd be interested in contributing back in principle, but first I have
to become a user, and the barriers to that are currently very high.
Especially given the existence of WebKit (which also has its problems,
so it's not like there isn't a niche available for a really nice
embedding solution).
My opinion is that having a richer embedding ecosystem around Gecko
would help bring in more contributors long-term and be a real boost to
all the projects that rely on Gecko, Firefox included. But that would
require more investment by Mozilla in make Gecko an attractive
embedding solution to begin with.
It's a catch-22 that can only be solved by somebody committing
significant resources to the problem. More resources than an
individual embedder can afford. I think Mozilla is the only party
that can get the ball rolling.
Cheers,
Ami.
Asa Dotzler
> On Wed, Apr 6, 2011 at 12:31 AM, Asa Dotzler<a...@mozilla.com> wrote:
>> No, that is not the question. There is no question about "caring" here and
>> it's both rude an insulting to phrase it that way.
>
> I think it's a legitimate question. Maybe the thing is to phrase it
> differently:
>
> "is embedding by third parties considered strategic enough to
> Mozilla's mission for it to invest its limited resources in it?"
Perhaps read the original post again?
I'll try to tl;dr it.
The person who leads the Mozilla project's embedding effort, Benjamin
Smedberg, does not think that in-process embedding capabilities,
including the current gtkmozembed, javaxpcom, and ActiveX work, are
strategic enough to Mozilla's mission for *anyone* to invest resources
there. The existing implementations are not only not strategic, they are
incomplete, problematic, and their maintenance costs far outweigh any
benefits so they are being removed from the Mozilla code repository.
Benjamin then goes on to say that after separate-process rendering is
implemented for 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.
So, if you care about a possible future multi-process embedding
implementation, and you're willing to help or can find others who are,
you may be able to get some help from Mozilla in making that a reality
> My opinion is that having a richer embedding ecosystem around Gecko
> would help bring in more contributors long-term and be a real boost to
> all the projects that rely on Gecko, Firefox included. But that would
> require more investment by Mozilla in make Gecko an attractive
> embedding solution to begin with.
Speaking for myself only here, I've heard this from many people for many
many years and I don't really believe it's the obvious win you and
others think it would be.
There's no free lunch and any efforts around building a better embedding
solution and an embedding ecosystem have to come from other projects. I
can think of several technical undertakings that, in my opinion, would
do far more to help bring in contributors and make Gecko better than
spending more efforts on embedding.
- A
Ami Ganguli
> There's no free lunch and any efforts around building a better embedding
> solution and an embedding ecosystem have to come from other projects. I can
> think of several technical undertakings that, in my opinion, would do far
> more to help bring in contributors and make Gecko better than spending more
> efforts on embedding.
Fair enough. I disagree, but I'm not in a position to do much about
it. At least this gives those of us who were hoping for a nice
embedding story for Gecko a chance for a clean break, so my
commendations to the Mozilla team for providing clarity on the issue.
Cheers,
Ami.
Asa Dotzler
> Fair enough. I disagree, but I'm not in a position to do much about
> it. At least this gives those of us who were hoping for a nice
> embedding story for Gecko a chance for a clean break
You seem to have missed the part where I pointed out Benjamen's call for
those interested in helping make a simple multi-process embedding story
happen.
Then again, those who will do nothing more to make it happen than "hope
for it" are probably wise to look to other solutions.
- A
Benjmain Smedberg
>
> I'll need to know what my options are going forward and how we will be able to control the browsers functionality (custom uri's trigger application launching, restricted access to uri's based on users credits etc.).
>
> Do I focus on using a swapping out GtkMozEmbed for a webkit browser or come up with something different.
gtkmozembed yourself, or in combination with other people who want to
try and maintain that code. You could switch to writing your kiosk as a
XULRunner app, or you could attempt to switch to webkit (plus all the
other libraries webkit requires, such as networking etc).
> What is the current status as regards xulrunner 2.0 ?
that the next following XULRunner will not contain gtkmozembed or the
ActiveX control code.
--BDS
Benjmain Smedberg
> The question is: does mozilla care about stuff other than their products at
> this point?
on this code. And the answer is that we should not. Our mission is
better served by focusing on the products that have the most impact and
leverage, which is currently Firefox and Firefox mobile.
--BDS
Ami Ganguli
> You seem to have missed the part where I pointed out Benjamen's call for
> those interested in helping make a simple multi-process embedding story
> happen.
>
> Then again, those who will do nothing more to make it happen than "hope for
> it" are probably wise to look to other solutions.
I didn't miss it. But I imagine that most people who would "hope" for
this are in a similar situation to me.
I can invest a small amount of time, but not enough to get over the
initial barrier needed to get started. It starts with the fact that
the documentation appears to be ancient. What documentation there is
is a bit off-putting - do I really need all of that stuff if my
use-case is just to render some HTML+CSS to an off-screen buffer?
The other avenues for getting involved in Mozilla offer baby-steps to
getting involved. You can learn a lot of the front-end, for example,
but starting out writing a plug-in. As near as I can tell, there are
no baby steps to getting involved in Gecko embedding.
Since I don't have the time to invest several months wading through
the source code and trying to figure out which documentation still
applies, I don't see any realistic way to contribute.
I am willing to give a couple of hundred Euros to Mozilla to
contribute towards a summer student, working with the support and
mentorship of some Mozilla people, to improve the documentation. I bet
others would too if you set up a donations page.
Cheers,
Ami.
g...@novadsp.com
> At least this gives those of us who were hoping for a nice
> embedding story for Gecko a chance for a clean break, so my
> commendations to the Mozilla team for providing clarity on the issue.
'embedding' covers a vast swathe of territory. It is relatively simple
to embed Firefox in an application. It is nigh on impossible to embed
(say) the SVG rendering system in an application, as it has dependencies
on ... almost everything. Firefox was designed to be a standalone
browser and not a collection of components that are easily plugged and
played.
As far as other browsers are concerned (Webkit/Chromium), they too
suffer from gigantism and interdependency. Webkit is extremely difficult
to 'embed' as the trunk relies on proprietary runtimes
(CF/Quartz/Quicktime). There is an OpenCF/Curl/Cairo route but this is
still (I believe) some way off oven-ready.
The Chromium team have done an amazing job in integrating alternatives
in Webkit but at an enormous cost. The current Chromium 'all' 'solution'
(in Visual Studio terms) contains around 500 sub-projects. Little wonder
the only people with the resources to do it are Google.
There is actually a Chrome embedding project but this relies on patching
a good number of sources and cannot be applied cleanly to any arbitrary
release.
Coming back to Firefox and the future, I believe that a good target
would be a Firefox configuration that had no runtime dependencies on
'chrome' and configuration files etc, i.e. reduced to an absolutely
minimal set of dynamically linked libraries. Hook all config/runtime
stuff so the embedding host can supply it in a format and from a
location that makes sense in the deployment environment. Extend and
expose functionality to make it trivial to run headless.
In an ideal world the minimal DLL set could be built and linked as a
static library, which would be useful on smaller machines - think
ucLinux and non-MMU processors. This implies having a build system that
feeds off trunk but provides a greater degree of flexibility. I'd want
to have the option to use static C/C++ runtimes as well.
The acid test for success would be to be able to deploy a single binary
that could display web resources, interactively or otherwise.
Note that the above applies to my current use case, which is embedding
in an existing Windows desktop app where HTML/SVG flexibility and
interactivity are a major boost. However, an embedding project would
probably want to support managed code too, be it C# or Python.
I think we could dispense with activex/flash plugin support.
All of this has to be done in a non-invasive way that takes full
advantage of Mozilla's hard work in testing, and verifying both quality
and adherence to standards.
I think this beyond the resources of a SOC project. Personally, given
the provision of an adequate wage, I'd love to have a crack at this. I'm
open to offers :)
Finally, my thanks too to the Firefox team. Amazing work and a great
product.
ATB
Jerry.
Martin Lutken
maintenance.
Could also help out myself, but have same concerns as described in the
previous post.
Actually I am investigating a crashbug which seems to have been
introduced between FF4 beta 6 and FF4 beta 7. The crash happens within
my embedded application ( wxWidgets ). I guess that will bring me some
more insight to the code and to mercurial, since I guess I need to do
bisection in Mercurial between the dates for those 2 releases trying
to figure out where the crash happens.
But I hear that XulRunner will still be supported, so perhaps I should
just switch to that. I have very limited GUI implemented so far and as
long as I can link in the PHP (Zend engine) runtime via plugin/
XulRunner something I might be fine.
But still if you can find a student I would happily donate money.
-Martin Lütken
Mark Finkle
solution is not high on Mozilla's priority list. Embedders each have a
different set of problems they are trying to solve and making a
modular library stack might be the best way to serve those needs.
However, making a modular library stack is exactly what Mozilla does
not want to do, since this is exactly not the problem we are trying to
solve. Mozilla wants to make products using the simplest, best
methods. Methods that result in the best codesize and performance.
One approach Benjamin and others have talked about is trying to find
an embedding solution that very closely follows the approach Mozilla
takes to building products. Firefox Mobile uses an out-of-process
system for rendering web content. The main UI process spawns a
separate child process and communicates with that process. User input
(mouse and keyboard) are sent to the child process and the web content
is rendered to shared image buffers which is then displayed in the
parent.
The child process doesn't even need a profile folder, one of the big
gripes with the current embedding solutions.
Would it be possible to create a generic, embedded system to allow a
3rd party application to spawn the child process and display the out-
of-process web content? Probably. There are a lot of unknowns and we
are still working the kinks out of the system.
The biggest advantage to this kind of solution is that it's aligned
with how Mozilla is shipping it's own products. Desktop Firefox is
moving to the same out-of-process system. There would be a large
overlap between Mozilla code and the embedding code.