[Sugar-devel] python hulahop article

[Luke Kenneth Casson Leighton]

On 7/27/09, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>  Though the gtk architecture is not too much service oriented, I think
>  it has some cases where the toolkit can be expanded by implementing
>  interfaces. Would be interested to see to which extend it matches the
>  XPCOM functionality.

 yes.  i did wonder whether this was the case.  i've been meaning to
investigate.

>  Also would be interesting to see if the new gtk mozembed widget and
>  gtkwebkit provide DOM APIs similar to what xulrunner provides through
>  XPCOM.

 ah.  right. take a deep breath.  let's start with the overview: i'm
the de-facto maintainer of the gtkwebkit DOM gobject bindings patch,
and on top of the webkit-gobject bindings, i created a patch to
pywebkitgtk which auto-generates the python bindings.

then, on top of _that_, i've created two files which - get this - make
pywebkitgtk and python-hulahop look near-as-damnit _absolutely_
identical.  you can see them here:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/pyjd/

and, you can clearly see that the original OLPC source code (on which
both hula.py and pywebkitgtk.py) shines through.

now we get to the bad news bit, i'm afraid.  the webkitgtk+
maintainers and the webkit reviewers are struggling to understand the
perspective from which python bindings to webkit are valuable [as the
equal and the peer of the javascript bindings].

some of it is due to the fact that the HTML5 spec simply does not
cover that which is in the de-facto javascript standard, but mostly
it's because i can't clearly explain it, as i'm running on intuition
more than i am logic, but... it's... never mind - just take a look at
some of the comments (briefly!  you have been warned!) and you'll see:
https://bugs.webkit.org/show_bug.cgi?id=16401

so, if you heed my advice, and you go direct to this:
http://github.org/lkcl/webkit/16401.master
http://code.google.com/p/pywebkitgtk/issues/
http://code.google.com/p/pywebkitgtk/issues/detail?id=13

then the glib/gobject bindings and the python webkit DOM bindings are
doing extremely well.  they work, they're powerful, and they're the
equal of pyxpcom+hulahop any day of the week.

on the other hand, if you listen to the perspective of the webkitgtk+
maintainers, and the webkit reviewers, the glib/gobject bindings and
the python webkit DOM bindings are a complete waste of time.

for example, the most recent bun-fight is over why you would want to
include XMLHttpRequest, and the answers are so numerous and so
obvious, and the disadvantages so onerous, that i'm having difficulty
both expressing and explaining it all.

>  To be clear, I don't think GObject has a component system that gets
>  close to XPCOM, but may be enough for your needs.

 well it may do, but it's certainly not being used / understood, if it does.

 the way in which the webkit gobject bindings are being auto-generated
should give a massive clue about what _not_ to do.
CodeGeneratorGObject.pm is 1500 lines of spaghetti perl, based on
CodeGeneratorJS.pm and CodeGeneratorObjC.pm as best i could throw
together.

 the whole approach is a complete dog's dinner, and if anyone is
thinking of replacing xpcom with a similar approach, all i can say is:
please don't.  if that's not enough warning, take a look at even just
the length of https://bugs.webkit.org/show_bug.cgi?id=16401 rather
than the content, and it should be clear as daylight that xpcom (or
technology like it) saves all that hassle.

so, i didn't mention this earlier, brendan, benjamin (because i was
looking for a moz-related forum to mention it), but thankfully tomeu
raised the question, to which i can now reply: from the webkit
bindings experience, i realise that it may be painful for the mozilla
team to maintain and use xpcom, but the alternatives can be truly
truly dreadful, and i trust that you will take this lesson into
consideration.

i'll be more than happy to discuss this further, perhaps i can come up
with some suggestions (especially after having been involved in
https://bugzilla.mozilla.org/show_bug.cgi?id=502234 as you know) if
you can point me at the appropriate forums.  finding the right moz-dev
forum is a bit hit-and-miss... :)

l.