when i started the pyjamas-desktop project i assumed that the "open-ness" that is written into the mozilla foundation charter would be an inviolate quantity that they would adhere to. taking this on faith i found the python-hulahop bindings of the OLPC project to be perfect to allow HTML5 DOM to be entirely (even exclusively) manipulated *python-side* instead of using javascript.
for anyone not familiar with the difference between pyxpcomext and python-hulahop, pyxpcomext was a project funded in 2000 by the mozilla foundation to *literally* embed python - making it a peer language of javascript - *within* a firefox browser. you downloaded a whopping 10mbyte extension for either linux or windows and you could do *not* just script language equals javascript and it would work, *including* accessing the *FULL* and complete DOM manipulation functions that we normally expect to have from javascript (exclusively, as it turns out in most peoples' mindsets).
python-hulahop on the other hand is (or was) a pygtk widget which allowed one to create a GTK window that happened to have a Gecko (HTML5/DOM) engine running in it, which *happened* also, amazingly, to provide one with the full set of DOM manipulation functions, starting from a python function GetDOMDocument() and going from there to the thousands of functions one normally expects to be the exclusive monopolistic domain of javascript.
the irony is that the python-hulahop project was only created so that the OLPC team could create their own embedded browser (in python), and they went to the trouble of using just a tiny fraction of the available functionality to implement the "Go" button, "Back" button, history and so on, all using the python bindings to the internal XPCOM interface that allows direct access to the full functionality of the Gecko Engine.
one other thing is needed to be explained before we can get on to what the problem is: XPCOM was "inspired" by Microsoft COM, and it *could* have been absolutely brilliant. COM is... deeply awe-inspiringly powerful, it is that flexible and ubiquitous. you may have heard me mention in the past that COM is what allows binary Active-X components compiled *TWO DECADES* ago to still be useful and useable on modern Windows (and Wine) systems today, even though in some cases the company that created them will have gone out of business.
technically the problem with XPCOM is that they forgot to implement co-classes, meaning that the only choice available to them is to *remove* quotes broken quotes functions and to constantly upgrade upgrade upgrade. this problem is at the heart of every single complaint for the past *TEN YEARS* by 3rd party developers using the Gecko Engine in java or c++ applications. they're SICK of having to recompile their applications to suit the mozilla foundation's schedule, particularly as it is such a mammoth task and may need to be done frequently (especially due to a security fix).
so with that as background we start to get some hints as to inherent problems that have been stressing out the developers for some considerable time. ...so what did they do about it? well, they responded to the "threat" of webkit (the engine behind chrome) by announcing a "speed, speed, speed" pathological binge - this was around 2010 or 2011. the ABSOLUTE top priority became not to be "open" - even to the extent of violating the spirit *and* the letter of the mozilla foundation charter - but to be "The Best". "The Fastest".
one of the first things that were removed was a single line from a header file - a "friend class" declaration. this one tiny change was utterly profound: it was a key absolutely critical change that prevented and prohibited the python-hulahop source code from accessing the XPCOM infrastructure. without that "friend class" declaration, there was absolutely no way that the GNU/Linux distros could take the standard gecko / xulrunner source code and have hulahop get that key strategic pointer to the Gecko Engine's top level XPCOM object.
when i pointed out how severe the consequences of this ill-considered unilateral decision were to the top people at the mozilla foundation, i was told "it's not a priority. speed is our priority".
when i pointed out that this violated the mozilla foundation charter i did not receive a response.
the second problem was that a couple of the functions (XMLHTTPRequest was one of them) had optional parameters that were only available via a hack of accessing the *javascript* parameter stack. when calling the exact same function from python, c++ or java, obviously this javascript-parameter stack would be empty.
basically i was running into the limitations of XPCOM not having co-classes, but from a different angle. the concept of co-classes are what gives e.g. c++ its "optional parameters" or its ability to have entirely different parameters for any given function, and the compiler works out which is the best one to use: co-classes is a *runtime* implementation of that, and it's utterly cool as it allows one to provide binary backwards-compatibility (you simply keep the old functions as-is and just add new ones which implement new functionality), a means to implement optional parameters (you provide functions with 3, 4, 5 and so on parameters) and more besides.
so i created a patch which extended the XMLHTTPRequest function out to 5 parameters (allowing me and anyone else to call it from c++ or java). the patch was *not accepted*. instead, some blithering idiot created an amazing idea of modifying the functions to take an "optional number of parameters" parameter. imagine having to write c++ code where one of the parameters told the compiler how many parameters the function had, and you start to get an inkling of quite how spectacularly stupid this idea of theirs really was.
again, when i raised quite how strategically vital this area was, and how important it was that this be discussed (and this incredibly dumb idea not allowed), i got nowhere.
the patch went in - and it entirely destroyed the ability of pyxpcom to correctly call those functions *AT ALL*. XMLHTTPRequest - an absolutely *critical* function to the operation of about 80% of pyjamas-desktop applications - had just been utterly destroyed by some dick being allowed to make arbitrary decisions with blatant disregard for other projects that critically depend on Mozilla Foundation funded technology.
so now, if you want pyjamas-desktop with a gecko (xulrunner) engine, you are forced to use versions 1.9.11.1 (the last known good variant from a stable distribution), or xulrunner 7.0 (which briefly made its way into debian/testing for a short period of time) and is - was - only really available in binary precompiled form from activestate.com in their komodo editor.
in 2011 i made a brief effort to compile up xulrunner 9.0 in the hopes of saving python-hulahop - making it a dependency - but the thought of becoming both an upstream and downstream maintainer of such a vast amount of code *UNFUNDED* was just too much.
so the summary is: congratulations to the mozilla foundation for violating your charter - for closing your doors to developers who were actually more interested in expanding the reach of your source code than you are. may you pay for following your chosen path by learning painfully for your closed-minded thinking.