> 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. -- http://mail.python.org/mailman/listinfo/python-list
