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

[bugzilla-daemon at webkit.org]

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





------- Comment #67 from lkcl at lkcl.net  2008-10-16 12:27 PDT -------
mark, hi,

all of the issues you raised i have either completed, explained
the roadblocks and/or reasoning why they have, will or cannot
be completed, or raised further questions,

so i - and others - are awaiting responses to those issues.

the patch as it stands is ... how-to-say... "feature-complete".
"self-consistent".  "is useable for production-ready purposes".
"is ready for release".

so, _yes_ there's a lot of code ... but... if there's a lot
of code - tough luck.  it does the job, it's useable, and i'm
disinclined - and have not yet received any incentive - to
do additional work to produce what will effectively be non-functional
and non-useful patches, just so that apple employees can get
their heads round the work.

you and others in apple are _paid_ to work on this - you therefore
have all the time in the world to sit down and work on understanding
it.


issues such as _how_ the code is to be used - such as the interface -
have _not_ been finalised, and discussions on how the code is to
be used have not proceeded.  alp raised the issue that the three
functions which have been added to WebKitWebView are not really
appropriate an interface, and i agree with him.

alp suggested *leaving out* those three functions, and i have
mentioned previously that i agree that that's a very good way
forward.

then, for anyone who does want to use this work, they can just
add in a temporary patch of only a few lines of code, and they're
off.

so, again, we're awaiting responses to the issues.

i did attempt a "partial approach".  it consumed large amounts
of my time and disrupted the maintenance of the "real" patch.

so, if given a choice between whether you, and others at apple, should
spend time and effort during well-paid working hours, to learn how
this patch works, or whether i should be asked to "dumb down" what's
been done into chunks of non-useful work, when i've got £25,000 of
debt hanging over my head, i'll choose... apple employees doing their
job and learning something new and exciting in the process!


the approach that i recommend that you take, due to the size of the
patch, is to accept it "as-is".  once that has been done, then i will
be _more_ than happy to raise bugreports and guide others and/or even
do additional work to address the issues.

by removing the (three) function that make it "operational", you
will be *stopping* the casual developer from assuming that the API
has been finalised, without hindering the interested developers
from cleaning up the work.

there is absolutely no reason why this decision should not be taken,
and there are many many reasons why it _should_ be taken.

not least is the simple fact that the sheer number of issues
that need to be addressed are _far_ too many to keep discussing
in one bugreport.

it's simply unmanageable.

so from a purely _practical_ perspective, accept the damn patch and
let's get on and make some damn progress.


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