[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

Mon Jul 13 03:56:13 PDT 2009

https://bugs.webkit.org/show_bug.cgi?id=16401

--- Comment #221 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-13 03:56:10 PDT ---
(In reply to comment #219)
> Speaking on behalf of the maintainers of the GTK+ port I'd like to reiterate
> what has been said in comments #194 and #195:
> 
> - After many rounds of review it's obvious by now that this patch can't be
> reviewed as is, and that no one (neither core WebCore people nor the
> maintainers of the GTK+ port) is willing to land unreviewed code.

 hiya xan,

 dave has kindly agreed to exactly that.  the patch has been reviewed dozens
 of times already; many of the issues have been addressed, whilst, as i
 initially recommended way back in ... september, i will be happy to help
 contribute, and to help others contribute, smaller manageable easily
 reviewable single-purpose patches that will of course always go through
 the standard review process.

> - This patch should be redone from scratch, 

 should?  probably, yes.  count me out, though - i've done it once,
 and i know what a bitch of a job it is.

> incrementally, and starting with a
> very small subset of the existing functionality.

 two people tried that.  they're both people who went to a lot of trouble
 to try to work with the apple review process, and they both, after finding
 it to be too difficult, went "no.  we're not doing that".

 so you should give serious consideration to listening to the wisdom
 learned and relayed from their experience, which is "no - bad idea".

 once is enough.

> See comment #194 for a
> suggestion of how to start doing this. Anyone is free to try this approach, 

 the flaw is simple: given that this patch already exists (and can be
 proven at a high-level using pywebkitgtk and pyjamas-desktop with the
 pywebkitgtk back-end enabled to actually work ) as i mentioned
 to dave, i seriously doubt whether you will find anyone willing to try.

 especially when they look through these comments and find such a stinging
 amount of hostility in the review process, towards contributions in this 
 highly-technical area.

 you have to remember that the areas of expertise required include:

 * c
 * c++
 * working knowledge of objective-c/c++
 * specialist working knowledge of the internals of WebKit / WebCore
 * gtk
 * detailed and full working knowledge of glib/gobject
 * a dynamic language (e.g. python, vala)
 * knowledge of code-bindings-generation for that language (e.g. codegen.py)
 * perl
 * autoconf.
 * the very latest GNU makeisms
 * experience in working at 2nd and 3rd hand in code generation
 * a very good memory
 * knowledge of javascript
 * knowledge of the W3C standards

 and even then, that's still not enough - you have to put that all
 together, for several weeks, so that you can stay on top of the
 whole lot.

 why do you think i worked and worked and worked on this and did not
 stop for eight weeks at 11 hour days?

> and
> we'll help as much as our time permits, but re-posting the huge monolithic
> patch won't get us anywhere.

 fortunately, it has got somewhere - see #214.

> - This bug is approaching the point where its length makes it unmanageable, 

 yes - that's why i suggested the "land it first, then fix issues later"
 approach.  initially that idea was met with completely inappropriate
 derision and scorn, and with "what makes _you_ so special, <insert
 derogatory swearword here>?" type direspectful and socially unhelpful
 comments, for which i haven't received an apology.

 eight months, 120 comments and several wasted man-months later, the
 wisdom of my initial suggestion is being understood, and has been
 given due consideration.  it's just sad that it's taken so long, and
 that otherwise good engineers felt the need to pour derision on this
 work, making the process of acceptance of it that much more painful -
 for themselves.

 a real pity.

 anyway.

 if you stick to the plan, you have my help.  eight months late, i now
 don't have a _complete_ map of this code in my head, and only have
 enthusiasm for going forward, not backwards. that having been said,
 i'm happy to lead the development of these bindings and see them
 through.

 once this patch is landed, as agreed, i will help create a list of
 individual bugreports, splitting out individual review comments
 and cross-referencing them.  (that itself is the kind of easy task
 which anyone can help contribute to, btw)

 things like:

 * rename Gdom to Webkit and GDOM to WEBKIT - this is an easy task
   that will be a tiny self-contained patch

 * fix the ref() unref() RefPtr<> issue - this is a specialist
   task that is again easy for someone who understands WebKit
   internals

 * write some perl to auto-generate the HTMLWrapperFactory code.
   this is an easy task that will be a tiny self-contained patch

 * fix the #includes of DerivedSources/gdom that have had to be added
   to several places, making sure that $srcdir != $builddir works.
   this is an easy task for anyone with specialist knowledge of gnu
   autoconf and gnu makeisms that will be a tiny self-contained
   patch.

 * fix the use of Custom and CustomGetter and CustomSetter.
   this is a faairly easy task that involves commenting out
   a few lines of the CodeGeneratorGObject.pm and seeing what
   breaks.  again, it will be a tiny self-contained patch

 so that's five small pieces of work that are self-contained and
 can all be done at the same time by different people, and will,
 post-patch-acceptance, result in the review process for #16401
 being fulfilled satisfactorily.

 there are plenty more like that, and i look forward to helping
 you and others identify them and i look forward to helping
 to review contributions to fix them.

 we have months of work to go on this as it is: this _working_
 i repeat PROVABLY WORKING first version is just the beginning.

 l.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.