python XMLHttpRequest

[lkcl]

>  all the methods by which you would have to deal with that GUI loop
> problem have to be asynchronous _anyway_... aaand, what the heck, why
> not just go with the flow and use the pyjamas.HTTPRequest or
> pyjamas.JSONService recommended services, neh?

 sorry to be adding stuff after-the-fact, but this is so ironic and
nuts i have to point it out.  underneath pyjamas.HTTPRequest and
pyjamas.JSONService, that's XmlHttpRequest... no not XmlHttpRequest
from javascript/web-browsers: XmlHttpRequest _from python_!  in the
MSHTML port, it's actually a COM interface wrapper around the
functions found in MSXML3 or MSXML6 DLL :)  and yeeees, it actually
works, in exactly the same way, identical in virtually every respect
across all the pyjd ports (with the exception of some bugs in
XulRunner/XPCOM), as the exact same javascript object found in web
browsers, with the exact same functions, event-handling callbacks and
so on.

 as an aside to that: i don't recommend you go looking into it (400
comments+ on a bugzilla...), but the development of the glib/gobject
bindings were a total nightmare.  not from a technical perspective,
but from what can only be described as ... well, one of the developers
decided quite early on that i must be some sort of egomaniac, and that
i had to be "taught a lesson".  this "lesson" involved finding any
excuse, method or rule (existing or made up) to jeopardise the webkit-
gtk glib/gobject bindings.  it didn't matter what it was - the answer
"no" _would_ be found.  i call this "technical bullying".

 in the case of the XmlHttpRequest functionality, the justification
was simple: "there are perfectly good gtk networking libraries out
there.  bug closed, that's the end of it.  I, Mark Rowe, Have
Spoken" (implication: **** off you dip-****).

 it took one of mark rowe's own colleagues, maciej, to point out that
the lack of XmlHttpRequest functionality for the objective-c webkit
bindings had forced at least one iPhone development team, to his
knowledge, to write an "XmlHttpRequest" look-alike - in objective-c!
and that, furthermore, _without_ the bindings to "real"
XmlHttpRequest, that reimplementation's effectiveness was severely
curtailed.  maciej pointed out that the "real" XmlHttpRequest has
access to "onload" event notification, XSS security, and all the other
stuff that makes XmlHttpRequest so powerful: interaction with the web
browser engine and its internal events, workings and state
information.

 now multiply that one experience by 300+ DOM objects, 2000+ W3C DOM
functions and 20,000 W3C DOM properties, all of which had to have glib/
gobject bindings, and you can see how easy it was for one egoistic
webkit developer to jeapordise the chances of success of the
pywebkitgtk project, based on their "superior technical knowledge"
and, if that wasn't superior enough, judicious use of turning a blind
eye to legitimate technically sound arguments.

 the _only_ reason that, after nearly 18 months of delay, webkit now
has _partial_ glib/gobject bindings that are useless as far as pyjamas-
desktop is concerned, is that a) i wore them down: the amount of time
being spent "countering" eevery single fucking argument was just far
too time-consuming b) i embarrassed them: the implications of being
banned from webkit and the manner in which that censorship was carried
done became shameful to them c) this is the important bit: lots of
people *other than me* have been clamouring for webkit-glib/gobject
bindings.

 so they _had_ to put the glib/gobject bindings in, after all that
effort spent fighting tooth and nail to prevent it... and not having
access to the key developer who worked on it (because of censorship)
it's been a bit of a bitch for them, and it's only about 80% complete,
after 6 months (the initial work only took 10 weeks!)

 upshot is: if anyone wants python bindings to webkit including the
full suite of DOM objects, you're going to have to get onto webkit-dev
mailing list and bitch like a trooper.  nicely, mind :)  the more
people ask (and raise bugreports about it), the less they can say
"no".

 l.