the purpose of this message is to highlight to webkit users and developers the increased flexibility and reach of webkit when it is extended to programming languages other than c++ and javascript.
appcelerator is one project that has stated clearly on its roadmap the provision for python and ruby bindings to its API, and thus should be paying particular attention. google (for android), should be paying attention in order to optimise application development where webkit is used as a front-end, as java bindings to the glib/gobject bindings would result in a performance increase of applications that would otherwise be forced to be implemented in javascript, on a platform (android) where performance is of absolute paramount importance. adobe should be paying attention if it wishes to extend adobe AIR to other languages, such as vala, python, ruby, java, perl etc. for all these projects, glib / gobject bindings to the webkit DOM model represent the best, quickest, most portable and the most flexible way to add language bindings. in the python case, thanks to pygtk's "codegen" which is a well-established, long-standing and extremely successful way to auto-generate python bindings to glib / gobject bindings, it took as little as 6 hours to create 1,500 functions and 350 python classes - most of which was spent going "err how does codegen work, and how do i get it to accept header files to make a useable .defs file?" so - vala bindings have been done here: https://bugs.webkit.org/attachment.cgi?id=27558 and python bindings have been done here: http://code.google.com/p/pywebkitgtk/issues/detail?id=13 [ruby unfortunately doesn't have an equivalent to codegen for python-gtk. incredibly and unbelievably, the ruby-gtk developers wrote 45,000 lines of gtk2 bindings code BY HAND, which is completely crazed, given that codegen.py exists and proves the concept, and given that ruby and python are quite similar dynamic languages.] why should there be language bindings to webkit anyway? well, perhaps that question is best asked of the OLPC SUGAR team, who abandoned the use of webkit and settled on XUL, precisely _because_ it has an understandable and language-independent interface (based on COM), on top of which python bindings could easily be added, in two stages (via python-xpcom), resulting in python-hulahop: http://wiki.laptop.org/go/HulaHop python-hulahop is the competitor to pywebkitgtk [with patch #13 applied to pywebkitgtk and #16401 applied to webkit] what have the OLPC developers been able to do that can't be done unless you have DOM bindings? they've written the web browser _in_ python. entirely. and then some. whilst they haven't actually done any DOM (web page) manipulation (which is tricky to get right) as demonstrated here: http://lkcl.net/pyjamas/pyjamas-xpdom.tgz they _have_ hooked in to things like DOM event management and event handling. why can't i just use the objective-c bindings to get python, ruby, etc. access? well - you can. good luck with that. no - seriously, why can't i just use the objective-c bindings? you can - it's just that the only platform on which there is well-known and significant use of objective-c is: apple mac. and, not least is the fact that the objective-c language bindings are specifically restricted to conform to the W3C DOM specification, despite that standard having been demonstrated as an unrealistic "ideal" that doesn't stack up against real-world requirements and real-world implementations. [the W3C DOM specification itself is full of comments stating how it should be done, right next to statements about how specific browsers _actually_ work. apple's objective-c bindings conform to "how it _should_ be done"]. so - you can perfectly well use objective-c, and from there you can get automatic and dynamic access to the language bindings, as _long_ as you pull in a whole bunch of infrastructure that has really only been tried and tested on the macosx platform. ... or, you can back the proven tried-and-tested portable platform-independent glib / gobject library, and write an auto-generator that will create language bindings of your choice (as demonstrated by both the vala and the python bindings). so - all this sounds great! developers get to write applications in their preferred programming language, instead of being forced to write javascript or c++ - sounds idyllic! what's the status? a synopsis of the 199 prior comments is here: https://bugs.webkit.org/show_bug.cgi?id=16401#c200 summary: it's not good. apple's developers have been both incredibly helpful and also incredibly UNhelpful, both at the same time. often exactly the same person. adding language bindings on top of an API that has 450 nearly 500 objects, 2,500 functions and over 20,000 individual properties is... deeply and hideously convoluted. it took nearly eight weeks of non-stop 11 hour days to get the bindings to the position that they are in (fully working, and useful). it was only by focussing so completely and continuously on the project that all the necessary information could be kept together (and kept "current"). this "all or nothing" burst of activity has a down-side: no cooperation with any other developer could have been possible. consequently, there was no review process: really helpful information went in (from apple, gtk developers, gnome developers and many other sources), and working code got spat out. with this "fait-accomplit" being presented, in the form of the #16401 patch, unfortunately, gustav felt it perfectly reasonable to state things like this: "So what if my project needs it? So what if pyjamas-desktop needs it? We need to figure out if it is the correct and best way of doing things for WebKit and the bulk of its users, not for your own pet project." because, in his mind, as a fait-accomplit, the work done cannot be trusted, and neither myself nor the projects i work on can be respected. this isn't a good way to make progress. there are several projects that are already using the glib / gobject bindings. there are a lot more people _waiting_ to use the glib / gobject bindings to webkit's DOM model. one developer has been brave enough to start using the glib / gobject bindings to XPath in webkit DOM, only to find that a constructor is missing, and that there is literally no way to create an XPath object! https://bugs.webkit.org/show_bug.cgi?id=16401#c199 overall, i get the distinct impression that there is some sort of pissing contest going on, and that apple's employees are absolutely _terrified_ of admitting that they might be wrong, and that webkit might go in a direction which they themselves have not forseen, or in a direction which they have not laid down the law on. so it's up to you - webkit users and developers - to say what you want. i can help advise on sticking-points / pit-falls which you might encounter. i've "been there, done that, written the funny inscription on the t-shirt" and come back reasonably unscathed to tell the tale. remember - KHTML's python bindings are unusable because of a simple mistake (reliance on a c++ RTTI compile-time switch, which absolutely everybody DISABLES by default when compiling KDE). the result is: a very obscure bug which results in incorrect object binding (multiple python objects get bound to the same c++ DOM object). these kinds of mistakes are tough as hell to find or even _notice_, and it's only by doing something as comprehensive as an entire desktop widget API (such as pyjamas-desktop) that you get the code coverage required to test every single corner of DOM language bindings functionality. if you don't care - that's fine: there's always python-hulahop. but if you do care, then you should begin by asking apple to answer for their actions and decisions - see end paragraphs, here: https://bugs.webkit.org/show_bug.cgi?id=16401#c200 i'd rather there weren't another 200 comments on this patch before it gets accepted. l. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev