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

[bugzilla-daemon at webkit.org]

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





--- Comment #236 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-15 13:45:26 PDT ---
(In reply to comment #214)
> After re-reviewing some of the comments, I think my comment that the patch
> "must be broken up in to smaller pieces" may be worded too strongly.  In
> Comment #76, breaking up the patch is suggested as a best practice for new
> contributors and will lead to quicker turnaround (reviews) on posted patches,
> but it's not a strict requirement.
> 
> However, since you're unwilling to break it up (and since willing to be
> patient), the next step would be to post a new monolithic patch for review
> addressing feedback in Comment #191 and Comment #194.

 ok - so, as we know, due to a misunderstanding, that happened, but it was
 believed that adam's work would be the way to move forward.  given that
 far too much was removed to make that possible, and given that my knowledge
 of eight months ago is of the original patch, i went from the original patch.

 so, with my original intentions to help move this forward still standing,
 but on a basis where i can actually contribute stuff that is useful to
 its users (pywebkitgtk and pyjamas-desktop) and so i can genuinely say,
 "yes, i can show and prove that this works, reliably", i ask you this
 question: 

 what, dave, would it take?

 i.e. what would you be willing to offer that moves this forward?

 use of adam's work as the initial basis is sadly not acceptable (to me
 as a free software contributor, or to pyjamas-desktop developers) and,
 given that i'm the  one that's offering to contribute,
 you should (necessarily) take that into consideration.

 here are some suggestions, and i would welcome input from anyone with
 any other ideas:

 1) a patch that makes the current libwebkitgdom.la a totally separate
    library, external to and absolutely nothing to do with webkit -
    not even maintained by webkit, not part of webkit.

    for this to happen, an opaque entrypoint function will be required,
    to get at probably..... DOMWindow.  or, a "setter" function will
    be required to set the pointer to Frame*.  

    and, critically, the CodeGenerator bindings scripts will need to
    be possible to run as separate stand-alone applications, and the
    IDL files will need to be installed in /usr/share/webkit/....
    somewhere.

    (this latter is exactly what XULrunner does, btw, because you need
    the IDL files from xulrunner for COM c++ application development.
    conceptually, there is no difference here).

    the nice thing about this is that if people want to shoot themselves
    in the foot by sticking to W3C standards, they can; if they want to
    put webkit-glib bindings onto a par with XulRunner's XPCOM bindings
    and with MSHTML's DCOM bindings, they can.

 2) a list of minor features - a compromise between what you believed
    we were agreeing to and what i believed that we were agreeing to -
    which would be acceptable to add prior to proceeding as agreed
    with landing the rest as-is.

    anyone can then take a look at the list - including myself - and
    see which items are time-consuming and which are manageable.

    the disadvantage of this approach is that each and every time
    a patch is submitted, you have _yet another_ massive review to
    perform, just to get things to the point where the patch can
    be landed [with some issues still to be dealt with]

    it has to be ironically pointed out that this overhead could be
    mitigated by landing the patch, of course, and then following up
    with smaller patches, but if there is a desire to stick to procedures,
    even if it causes stress and distress, then i'm not going to stop
    you - just don't lay the blame at my door if things remain too much.

    however, what might work would be to submit "patches-to-patches"
    for review, i.e. take the current patch as-is (attachment 32633)
    and we agree that "minor feature" patches will be reviewed.

    if the complete list of "minor feature" patches is fulfilled,
    then the attachment 32633 plus the accompanying minor-patches
    are landed "as-is", and then we move forward to fix any other
    remaining outstanding (larger) issues. 

    this is... sort of a less formal / less strict version of 4) or
    5) below.

 3) we wait - for someone else to come up with the goods.

    i'm quite happy to do this - it's just that... we end up with
    disappointed and frustrated users by doing so.

    i can manage doing .deb builds of webkit-glib/gobject for 32-bit
    and 64-bit debian users, and i can do customised/embedded builds.
    and even macports.org builds.

    but... windows?  pshahh.  tried it once.  took eight days.  not
    me 'guv :)

    so - we wait, but waiting delays delivery.  fortunately, for
    pyjamas-desktop users, there is always xulrunner, so it's the
    other projects that suffer.

 4) a branch.

    the patch is landed as-is.... in a branch.  in that way, people can
    contribute merges and fixes, and move forward.

    merges are the biggest time-consumer of all, way beyond making
    modifications.

    one of the primary motivations behind my recommendation that the
    patch be landed and then worked on post-landing is due to the fact
    that merges, using anything-other-than-webkit-svn, is tricky and
    time-consuming.

    by working from a webkit branch _in_ the webkit svn, there are
    several distinct advantages:

    a) the burden of merges goes away
    b) the work is still being carried out in one "central" location
       under the watchful eye of the webkit team
    c) the review process can still be carried out, as usual.

  5) work is carried out elsewhere (not using webkit svn)

    patches and reviews take place elsewhere, but continuing to utilise
    the bugtracker, here.

    smaller patches could be submitted for review (here), with reviewers
    being made keenly aware that they are reviewing an external source tree
    not a webkit one, with a view to it being accepted _by_ webkit.

    in this way, the process of development of the work is acceptable
    and manageable; the eventual acceptance is trustworthy.

    disadvantage: disconnect between webkit svn and whereever-it-is,
    making merges timeconsuming (and cumbersome).

  6) other.

thoughts?  i'm interested to hear from anyone at all, world-wide, who is
willing to help make sound strategic or technical contributions to this
discussion, with a view to providing useful and useable c-based
glib/gobject DOM bindings.

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