On Monday, March 28, 2011 10:03:11 PM UTC+1, Benjamin Smedberg wrote: > 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.
no it's not - the python-hulahop widget uses GTK just like firefox does: it works perfectly, and it even provides access to XPCOM so that python-xpcom can get hold of the NPAPI and use DOM functionality in exactly the same way that javascript does [when xulrunner is embedded in firefox] > We never solved it fully, and each embedder has had to > spend lots of time tweaking things. perhaps it might be worthwhile for the mozilla foundation to find - and fund - the people who _do_ understand these things, rather than totally abandon existing efforts and leave entire communities completely without support: http://lists.sugarlabs.org/archive/sugar-devel/2011-June/031865.html > * 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 no it's not. if you have things like XPCOM which is a dynamic "object model" interface, you don't *need* "binary compatibility" - you just need to make sure that XPCOM works. XPCOM, which was based on (inspired by) microsoft's COM, is just as misunderstood, it seems, as COM is. the benefits of Common Object Model technology are just... i cannot emphasise enough how powerful they are. this is something that the Free Software Community as a whole simply does NOT get, to its detriment. microsoft dominated computing for nearly two decades thanks to COM/DCOM. apple dominates its sector through Objective-C, at the heart of which is, yes, you guessed it: a type of Dynamic Object Model system. > which is not worth the benefits. what??? completely abandoning and orphaning entire communities is seen as "beneficial"?? > * 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. that's actually very sensible. gtkmozembed is pretty lame. it doesn't go nearly far enough. without dynamic language bindings - i.e. without access to what's actually *in* the web page, who the hell just wants to drop a web rendering engine into an application? you didn't go far *enough*, ben. people want to be able to drop in widgets into the middle of the HTML page: they want to be able to respond interactively to events (DOM events) - but not just in c, it has to happen in *all* programming languages, be it c, c++, java, python, ruby, perl - anything. now. that *is* possible with python-hulahop. so do you think it would be a good start for the mozilla foundation to adopt python-hulahop as the beginnings of reversing this trend towards isolation of the mozilla foundation from absolutely everything but javascript, javascript, javascript and firefox, firefox, firefox? > 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. hulahop manages absolutely fine. all that's written in python. it just works. > 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. it's not enough. you need to have the "dual worlds" functionality. a foot in the "embedded widget" door *and* a foot in the DOM world, via XPCOM. hulahop provides exactly that. the problem is that because it's "third party", it's absolute hell for non-funded part-time free software community members to keep it up-to-date, and the mozilla-foundation-driven release cycle does *not* include hulahop, meaning that releases like xulrunner 10.0.2 go out the door with serious memory corruption problems that, more by luck than judgement, happen *not* to be hit by firefox... but that hulahop runs smack into with a segfault. what is the mozilla foundation intending to do about this, especially given that entire free software communities have been completely cut off by these decisions (the OLPC team and the pyjamas-desktop team), and that the mozilla foundation is at risk of not fulfilling its manifesto as a result. l. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
