[webkit-dev] status update: webkit gobject bindings [svn r46395]
this is a progress report for archival and informational purposes on the upkeep of bug #16401, providing useable and useful glib / gobject bindings to the full webkit DOM implementation. pending inclusion in webkit svn, the code is being kept up-to-date on an ad-hoc basis at http://github.org/lkcl/webkit/16401.master. as the last 16401.master update (svn r44624 or so) was from a few months ago, yesterday was update to svn r46395 day, which was uneventful except for two major things: * updating to latest svn forced the use of the latest (git) revision of libsoup, which in turn incorporated a critical bugfix. * since the last change, a new attribute concept has been added to webkit IDL files: [reflect] and [reflectURL]. an initial attempt to ignore any properties with such attributes was made, but that quickly turned webkit-gobject (and pywebkitgtk) into something completely unusable, and it had to be fixed immediately. in short, then, the latest svn update has been done successfully without loss of functionality to the bindings, and the python bindings (pywebkitgtk) which in turn depend on webkit glib/gobject bindings have also suffered no loss of functionality, either. regarding the #16401 patch work, david kiltzer made an excellent suggestion two weeks ago which paved the way to split the 6,000-line patch down into smaller patches. individual discussions can now take place and be easily tracked. it is anticipated that if a discussion shows signs of getting too complex, covering too many issues, that it be split into further separate bugreports. so far, there are fifteen separate patches (all linked as blocking #16401) with more expected. the biggie is CodeGeneratorGObject.pm: everything else is infrastructure. CodeGeneratorGObjectLibrary1.pm is the first split, and it is anticipated that this file be split further (on an arbitrary 50% basis unless someone voices a better suggestion which saves developer time and money). patches to GNUmakefile.ams have *not* yet been submitted. all patches but the one to WebKitWebFrame have *zero* impact on the normal compilation process of webkit, regardless of compile-time options. all of the remaining patches simply add code that will remain completely unused, until the GNUmakefile.ams and WebKitWebFrame are also patched. the addition of LANGUAGE_GOBJECT to the IDL files has thrown up some oddities, just in the review process, such as #27603. it turns out that the HTML5 spec has moved on, making certain exceptions in the IDL files unnecessary. this is very fortunate, because all the work put into the gobject bindings is made useless if there are features missing from them. in that regard, it may be of interest to note these curious questions: https://bugs.webkit.org/show_bug.cgi?id=27435#c10 https://bugs.webkit.org/show_bug.cgi?id=27435#c13 the summary of these questions, regarding provision of XMLHttpRequest via language bindings, is basically, wtf?? :) and, as can be seen by the extensive but non-exhaustive replies, XMLHttpRequest via language bindings is a critical and integral part _of_ the language bindings. the summary lesson, shown by the only project currently and fully using the webkit gobject bindings (pyjamas desktop) is that it is absolutely absolutely necessary to have access to absolutely absolutely everything [in the DOM] - or you might as well not bother. at all. with respect to sam and alexey, the curious questions that you usefully raise highlight quite how much of a mismatch of understanding and appreciation for what is possible with web browser language bindings there still is, in the webkit community. [overall this leaves me somewhat flustered because i must be failing to communicate correctly just how powerful this stuff really is]. also it's worth noting that pyjamas desktop provides an indirect route to comparing xulrunner language bindings against webkit language bindings (and the plan is to add MSHTML as well, using python-win32com). so far, the differences are trivial and small, with webkit being the 2nd class citizen with respect to its provision of access to the DOM. one of the reasons why i am fighting the reviewers so hard is to ensure that what is accepted into webkit svn does not result in the webkit gobject bindings falling behind its peer, python-xpcom and MSHTML. simple differences which can be trivially worked around are tolerable, but significant differences, such as missing out entire areas of functionality such as XMLHttpRequest or having properties which are strings in MSHTML, KHTML and python-xpcom but are integers in webkit really cannot be tolerated. if you are interested in seeing webkit obtain useful and useable free software language bindings, how can you help? * first, compile up the patched #16401.master version of webkit from github * second, compile up the patched version of pywebkitgtk: http://code.google.com/p/pywebkitgtk/issues/detail?id=13 * third, install pyjamas (see
Re: [webkit-dev] status update: webkit gobject bindings [svn r46395]
Maybe zecke's email wasn't clear. Here's another attempt: Brevity is the soul of wit --William Shakespear Verbosity hinders your goals. dave On Sun, Jul 26, 2009 at 11:52 AM, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: this is a progress report for archival and informational purposes on the upkeep of bug #16401, providing useable and useful glib / gobject bindings to the full webkit DOM implementation. pending inclusion in webkit svn, the code is being kept up-to-date on an ad-hoc basis at http://github.org/lkcl/webkit/16401.master. as the last 16401.master update (svn r44624 or so) was from a few months ago, yesterday was update to svn r46395 day, which was uneventful except for two major things: * updating to latest svn forced the use of the latest (git) revision of libsoup, which in turn incorporated a critical bugfix. * since the last change, a new attribute concept has been added to webkit IDL files: [reflect] and [reflectURL]. an initial attempt to ignore any properties with such attributes was made, but that quickly turned webkit-gobject (and pywebkitgtk) into something completely unusable, and it had to be fixed immediately. in short, then, the latest svn update has been done successfully without loss of functionality to the bindings, and the python bindings (pywebkitgtk) which in turn depend on webkit glib/gobject bindings have also suffered no loss of functionality, either. regarding the #16401 patch work, david kiltzer made an excellent suggestion two weeks ago which paved the way to split the 6,000-line patch down into smaller patches. individual discussions can now take place and be easily tracked. it is anticipated that if a discussion shows signs of getting too complex, covering too many issues, that it be split into further separate bugreports. so far, there are fifteen separate patches (all linked as blocking #16401) with more expected. the biggie is CodeGeneratorGObject.pm: everything else is infrastructure. CodeGeneratorGObjectLibrary1.pm is the first split, and it is anticipated that this file be split further (on an arbitrary 50% basis unless someone voices a better suggestion which saves developer time and money). patches to GNUmakefile.ams have *not* yet been submitted. all patches but the one to WebKitWebFrame have *zero* impact on the normal compilation process of webkit, regardless of compile-time options. all of the remaining patches simply add code that will remain completely unused, until the GNUmakefile.ams and WebKitWebFrame are also patched. the addition of LANGUAGE_GOBJECT to the IDL files has thrown up some oddities, just in the review process, such as #27603. it turns out that the HTML5 spec has moved on, making certain exceptions in the IDL files unnecessary. this is very fortunate, because all the work put into the gobject bindings is made useless if there are features missing from them. in that regard, it may be of interest to note these curious questions: https://bugs.webkit.org/show_bug.cgi?id=27435#c10 https://bugs.webkit.org/show_bug.cgi?id=27435#c13 the summary of these questions, regarding provision of XMLHttpRequest via language bindings, is basically, wtf?? :) and, as can be seen by the extensive but non-exhaustive replies, XMLHttpRequest via language bindings is a critical and integral part _of_ the language bindings. the summary lesson, shown by the only project currently and fully using the webkit gobject bindings (pyjamas desktop) is that it is absolutely absolutely necessary to have access to absolutely absolutely everything [in the DOM] - or you might as well not bother. at all. with respect to sam and alexey, the curious questions that you usefully raise highlight quite how much of a mismatch of understanding and appreciation for what is possible with web browser language bindings there still is, in the webkit community. [overall this leaves me somewhat flustered because i must be failing to communicate correctly just how powerful this stuff really is]. also it's worth noting that pyjamas desktop provides an indirect route to comparing xulrunner language bindings against webkit language bindings (and the plan is to add MSHTML as well, using python-win32com). so far, the differences are trivial and small, with webkit being the 2nd class citizen with respect to its provision of access to the DOM. one of the reasons why i am fighting the reviewers so hard is to ensure that what is accepted into webkit svn does not result in the webkit gobject bindings falling behind its peer, python-xpcom and MSHTML. simple differences which can be trivially worked around are tolerable, but significant differences, such as missing out entire areas of functionality such as XMLHttpRequest or having properties which are strings in MSHTML, KHTML and python-xpcom but are integers in webkit really cannot be tolerated. if you are interested in seeing
Re: [webkit-dev] status update: webkit gobject bindings [svn r46395]
Let me put it even more strongly. Luke, you need to stop sending long, rambling emails to the list. Many people have complained about both the form and content of your messages, and no one but you has spoken up that they find these emails useful. If you don't have the judgment to determine what messages are relevant to others, or how to make them concise enough to be readable, then your posting privileges will be suspended. WebKit is open to the public, but that doesn't give you the right to harass our contributors. Regards, Maciej On Jul 26, 2009, at 1:52 PM, David Levin wrote: Maybe zecke's email wasn't clear. Here's another attempt: Brevity is the soul of wit --William Shakespear Verbosity hinders your goals. dave On Sun, Jul 26, 2009 at 11:52 AM, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: this is a progress report for archival and informational purposes on the upkeep of bug #16401, providing useable and useful glib / gobject bindings to the full webkit DOM implementation. pending inclusion in webkit svn, the code is being kept up-to-date on an ad-hoc basis at http://github.org/lkcl/webkit/16401.master. as the last 16401.master update (svn r44624 or so) was from a few months ago, yesterday was update to svn r46395 day, which was uneventful except for two major things: * updating to latest svn forced the use of the latest (git) revision of libsoup, which in turn incorporated a critical bugfix. * since the last change, a new attribute concept has been added to webkit IDL files: [reflect] and [reflectURL]. an initial attempt to ignore any properties with such attributes was made, but that quickly turned webkit-gobject (and pywebkitgtk) into something completely unusable, and it had to be fixed immediately. in short, then, the latest svn update has been done successfully without loss of functionality to the bindings, and the python bindings (pywebkitgtk) which in turn depend on webkit glib/gobject bindings have also suffered no loss of functionality, either. regarding the #16401 patch work, david kiltzer made an excellent suggestion two weeks ago which paved the way to split the 6,000-line patch down into smaller patches. individual discussions can now take place and be easily tracked. it is anticipated that if a discussion shows signs of getting too complex, covering too many issues, that it be split into further separate bugreports. so far, there are fifteen separate patches (all linked as blocking #16401) with more expected. the biggie is CodeGeneratorGObject.pm: everything else is infrastructure. CodeGeneratorGObjectLibrary1.pm is the first split, and it is anticipated that this file be split further (on an arbitrary 50% basis unless someone voices a better suggestion which saves developer time and money). patches to GNUmakefile.ams have *not* yet been submitted. all patches but the one to WebKitWebFrame have *zero* impact on the normal compilation process of webkit, regardless of compile-time options. all of the remaining patches simply add code that will remain completely unused, until the GNUmakefile.ams and WebKitWebFrame are also patched. the addition of LANGUAGE_GOBJECT to the IDL files has thrown up some oddities, just in the review process, such as #27603. it turns out that the HTML5 spec has moved on, making certain exceptions in the IDL files unnecessary. this is very fortunate, because all the work put into the gobject bindings is made useless if there are features missing from them. in that regard, it may be of interest to note these curious questions: https://bugs.webkit.org/show_bug.cgi?id=27435#c10 https://bugs.webkit.org/show_bug.cgi?id=27435#c13 the summary of these questions, regarding provision of XMLHttpRequest via language bindings, is basically, wtf?? :) and, as can be seen by the extensive but non-exhaustive replies, XMLHttpRequest via language bindings is a critical and integral part _of_ the language bindings. the summary lesson, shown by the only project currently and fully using the webkit gobject bindings (pyjamas desktop) is that it is absolutely absolutely necessary to have access to absolutely absolutely everything [in the DOM] - or you might as well not bother. at all. with respect to sam and alexey, the curious questions that you usefully raise highlight quite how much of a mismatch of understanding and appreciation for what is possible with web browser language bindings there still is, in the webkit community. [overall this leaves me somewhat flustered because i must be failing to communicate correctly just how powerful this stuff really is]. also it's worth noting that pyjamas desktop provides an indirect route to comparing xulrunner language bindings against webkit language bindings (and the plan is to add MSHTML as well, using python-win32com). so far, the differences are trivial and small, with webkit being the 2nd class citizen with respect to its provision of access to the DOM. one of
Re: [webkit-dev] status update: webkit gobject bindings [svn r46395]
On Sun, Jul 26, 2009 at 4:24 PM, Maciej Stachowiakm...@apple.com wrote: Luke, you need to stop sending long, rambling emails to the list. For what it is worth, I completely agree with Maciej's statement. I am not (yet) a committer and have no association with Apple or any of the other WebKit big guns so I would hope my opinion would not be seen as biased. Therefore I hope Luke can listen when I say I do not find long rambling emails from anyone very useful or enlightening. I imagine I am not alone. Also as one of the main developers of the Haiku port of WebKit I have found the project open and helpful to a small and somewhat obscure port. This has inspired me to want to contribute back to WebKit in general areas that can help everyone and not just my port. I find such a tit-for-tat approach one of the great benefits of open source development. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
