[summary to brendan and chris: chris, brendan, hi, i'm cc'ing you on this because the OLPC team have been forced into making a decision to move away from using xulrunner technology, as a direct result of the decision made to reduce python-xpcom to third party status: it's taken this long for the lack of support from the mozilla foundation for this code to "fall by the wayside", and catching up is going to be a complete bitch. unfortunately, the replacement code being used, webkit with gobject bindings - which i designed - was "revision 0.0" and has severe fundamental design flaws which the OLPC team will *only* encounter much much later down the road, by which time it will be too late for them to back out of].
On Tue, Feb 21, 2012 at 3:17 PM, Gonzalo Odiard <gonz...@laptop.org> wrote: > I have read you. ok, good. sorry, you didn't say that, earlier. > you don't need repeat. good! > In first place, is really bad have this information now, and not 8 months > ago, well... tough. i wasn't consulted or informed of the decision, yet those people who are on the olpc sugar-devel mailing list will have seen my contributions and discussions some time back, discussing the fact that pyjamas-desktop uses hulahop, and how incredibly grateful i was - am - that the OLPC team went to the trouble of writing hulahop. so it was only pure chance that i encountered the discussion at all. > a lot of work was spent porting Browse to webkit, > and the result is no so bad like you say. gonzalo: despite saying that you've read what i wrote, you're telling me that you haven't absorbed what i wrote. i said that - and this is from direct first-hand experience - that it is *only* when you have applications that are a bit larger than "simpull web pagizzz" that you end up with crashes and instability. > Of course, only few developers are using it, then do not have a real field > use. preeeeeciselyyyyyy. whereas the pyjamas-desktop project has 100% code-coverage of EVERY feature present in the DOM bindings, and thus if there is even the slightest error or even one tiny, tiny function missing, the problems are encountered pretty much within 5 minutes of testing. usually it's enough to run the Helloworld.py example, KitchenSink.py example, the JSONRPC example, the Mail example and the SVGCanvas example. that pretty much covers about 99.5% of the functionality, in under 5 minutes. > The decision to move to webkit was based in: > * the number of problems with gecko > * many other projects using webkit. In general more clients for a library, > means more eyes and more bugs solved. in general, yes, but "in general" means for a nice, easy, simple library which doesn't require gigabytes of source code downloads, doesn't involve having to know TWELVE separate and distinct programming technologies in order to even get to grips with the code, let alone understand what's involved in the design decisions behind the gobject bindings. the number of people in the world who actually understand the issues involved is one: me (because i designed the code, and the successor bindings, pythonwebkit). the number of people in the world who have the intelligence to be able to fix these MASSIVELY complex issues is about three, possibly four. the number of people _listening_ to what i'm saying is however zero, and the number of offers of money to _fix_ the problems is also zero. now, if this (pythonwebkit or hulahop) was sponsored by the mozilla foundation, or by google, it would be fine, because you could have someone paid to sit for 3-4 weeks to fix and maintain the code (either the hulahop code or the gobject bindings) ... but that isn't the case, here, is it? the mozilla foundation *deliberately* moved pyxpcomext to 3rd party status - that was a decision taken by brendan because he misunderstood the importance of python-xpcom, believing it to be solely and exclusively useable inside the python <script language="python"> plugin for firefox. that plugin was a complete bitch to maintain for win32: the only people with the resources to tackle its compilation were novell, and even they gave up after succeeding once and only once to get xulrunner 1.8 up and running. so *if* that was the *only* usage for python-xpcom, then the experiment and the money spent on that experiment would have been a sensible declaration of "failure" because the number of people who _actually_ install python as a whopping 10 *MEGABYTE* plugin into firefox across multiple platforms in order to be able to do <script language="python"> is very, very small. unfortunately, though, there was a crossover point where the existence of the python-xpcom code (NOT the pycomext plugin) encouraged the OLPC team to create hulahop, which provided as you know the means to do python embedding from a declarative programming perspective *not* a script language=python perspective *and* provided the critical, critical DOM interaction from python by simultaneously allowing access to the NS XPCOM interfaces. ... but the mozilla foundation was *not* aware of the significance of python-hulahop, and so reduced python-xpcom (hulahop's critical dependency) to third party status. todd whitemann is now struggling to keep up with its maintenance (see for example the massive patch to remove PRBool and replace with bool - that was done in all mozilla-central code but *not* done in the same patch on the pyxpcomext repository, was it?) we now have a situation where because python-xpcom (and hulahop) are not part of the standard testing by the mozilla foundation, i was extremely lucky to have xulrunner 9 actually work, yet *immediately* the situation totally fell apart for xulrunner 10.0.2 and bugs which were *not* encountered in firefox releases have slipped past the radar and cause xulrunner to segfault when it is used via hulahop. i haven't even _looked_ at xulrunner 11 yet! so basically, you're unfortunately in a very tough situation, because the code that you've moved to is not ready for use, but the code that you've moved *from* is not being maintained! so to fix this, from the xulrunner perspective, what it's going to take is to actually pay someone to sit down full-time and get this sorted, then pay them to be available for consultancy to explain things to people when there are problems, and to re-integrate python-xpcom *back* up to proper status within mozilla's codebase and even better would be for the mozilla foundation to adopt hulahop in its entirety and to have its use integrated into the standard testing and release cycles. god only knows how the webkit stuff is going to be fixed because the core webkit developers worked extremely hard to destroy the webkit-gobject work that i did, and i'm literally the only person in the world who fully understands it enough to know what the problems are. if you're _really_ going to insist on sticking with webkit then you'll need to think of a solution to that, and get onto the webkit-devel mailing list and raise the issue there, see how far that gets you. l. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel