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

Sun Jun 7 08:50:14 PDT 2009

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

------- Comment #200 from lkcl at lkcl.net  2009-06-07 08:50 PDT -------
rrright - time for a recap.

* initial progress made was fast, fun, and useful.  python bindings on top of
the glib bindings (pywebkitgtk) and then a desktop widget API on top of that
(pyjamas-desktop) allowed for rapid, full and nearly complete development of
the glib / gobject bindings.  about the only thing that was missed out was
"remove event listener".  mark and the other apple employees were extremely
helpful in advising on key critical webkit issues, in particular refcounting,
and in how the javascript and the objective-c bindings work, both of which were
copied and learned from, to create the gobject bindings.

* review was not done for several weeks because it was not understood that a
"?" has to be put next to patches.

* a review cycle began, which comprised several levels:

1) compliance with webkit coding standards.  communication on exactly which
parts of the coding standards were required to be complied with was in some
cases not made explicit enough, but was eventually understood.

2) downright silly bugs - it's always good to find these.

3) an explanation of refcounting that was beyond the ability of three separate
engineers to understand, and a request to comply with the c++ webkit standards
on refcounting rather than the "mixed" manual approach, which the three
separate engineers all attempted to implement, independently, without success

4) apple making it explicitly clear that compliance with de-facto (industry)
standards must NOT be done; that even if it jeopardises developers' ability to
utilise the gobject bindings and terminates any possibility that a project
could ever make use of the gobject bindings, compliance with the W3C DOM
standards is of absolute pathological and paramount absolute 100% top priority.

* a request was made, by apple employees, to two separate engineers, to provide
a much "simpler" patch - one which would help them to understand what was going
on.  the first engineer - a free software developer with debts approaching $USD
50,000 and with irregular income of only around $1000 per month - did some
initial exploration into creating a "simpler" gdom patch (attempting to add
GdomNode only) and found it to be a complex process that would by default pull
in vast amounts of dependent objects (such as GdomNodeList, and then GdomAttr,
and so on).  actually creating a "simpler" patch that would compile and would
be verifiable turned out to be too challenging.  the request was therefore
denied.  the second request, made to a separate engineering team, was also
denied on the basis of the team running out of time and money to spend [on
educating apple employees as well as their own project].

in both cases, it was made very clear that billion dollar companies such as
apple really shouldn't go asking for freebies, with the implication being that
it is the responsibility of the webkit maintainers to take the time and utilise
their own corporate money to understand what is going on, or, if that is not
possible, to delegate responsibility to someone who _does_ understand.

* the complexity of the patch began to take its toll, leading the apple
engineers to begin to take drastic measures to try and reduce the amount of
complexity that they had to be involved with, and thus reduce the amount of
stress that they would face.  one of the psychological methods deployed was to
clearly and explicitly state a lack of trust in the original engineer's work,
and to begin to  belittle both the engineer and the project that had inspired
the original gobject bindings work.  the reaction of the engineer was one of
frustration, disbelief and coarsely-expressed outrage, mixed in with attempts
to provide reasonable counter-arguments to the increasingly hostile,
increasingly disrespectful and increasingly non-technical or goal-post-moving
arguments being dreamed up by apple engineers.

the "arguments of last resort" being utilised by apple engineers were simply
silence or to state "because we said so".

thus, the opportunity for progress is terminated by a billion-dollar
corporation.  "because we said so".

* contributions by other engineers were welcomed, mostly because the engineers,
not having the practical experience of developing a fully-blown Widget API on
top of the webkit / gobject bindings, acted according to apple's dictats.  the
original developer could no longer work with these engineers because of removal
of critical functionality that left no way to do any testing (by running
high-level test suites using the Widget API that was based on webkit/gobject).

* suggestions to relax the coding standards and land the patch as-is, and then
create much much simpler follow-up patches to correct any issues, and to use
the webkit bugtracker to record outstanding issues, were dismissed out-of-hand.

* research showing that the de-facto javascript standards are leading the way
in all other language bindings in all other leading browser engine technology -
MSHTML, KHTML, Gecko - has been ignored, despite five requests that apple
employees review the researched material showing that webkit will be the only
web browser engine in the world that does not comply with the de-facto
javascript standards, thus making it incredibly awkward or literally impossible
to use.

* developers who are now beginning to utilise the glib / gobject bindings are
finding that functionality which has been shown and proven to be required by
the original engineer (which the apple employees refuse "because we said so" to
accept) is actually, in fact... required!

given this summary, suggestions on how to proceed, to provide a full set of
glib / gobject language bindings, that provides a _useful_ and _useable_ set of
language bindings, might be a good idea to discuss.  a good way to begin might
be for apple's webkit team to make a clear statement regarding their position
on language bindings, and to clearly and unequivocably state whether it is
apple's intent to dominate, dictate and stifle development or whether it is
their intent to act as a facilitator and accelerator of the development and the
reach of this strategically important piece of software.

-- 
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.