[Sugar-devel] Browse and the move to WebKit

[lkcl luke]

[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 <gonzalo at 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.