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

Mon Jun 8 10:25:22 PDT 2009

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

------- Comment #208 from lkcl at lkcl.net  2009-06-08 10:25 PDT -------

> If my tone was too personal for you,  I apologize.

 thank you - that makes a big difference.  i'm sorry if i jumped to conclusions
( i'll respond out of order with the rest as i wanted to say that first ). 
regarding your offer to help if you had time - that's really appreciated, too. 
i can recommend staying well clear, however, unless you have significant time
available (or, as you say, a good reason). goodness knows where martin got his
expertise from to be able to tackle this and rework it in the short amount of
time that he did, but dang i have an enormous amount of respect for him for his
contribution.

 i looked at #15914, and it would be a good idea to follow that example - i see
that the functionality that was added fitted into four patches, two of which
were dependent on the other.  whilst it seems a very good approach to take, the
difference between the two is that the unicode update _did_ fit into (roughly
equally sized?) separate patches, and the glib/gobject bindings... well...

 here's reasons against the idea (even though it's a good one):

 1) in the case of CodeGeneratorGObject.pm, virtually all of the functionality
that's in there is required to support even just _one_ class, and the
inter-dependence between the DOM classes makes - made - it pretty impractical
to consider filtering them out.

 even if you want to do something as basic as "Node" - to create GdomNode -
take a look at Node.idl, you can see _whoa_, it depends on Object, NodeList,
EventTarget, EventListener, Document, NamedNodeMap - i just... gahh, the
thought of 

 in other words, the code, thanks to the inter-relationships between the DOM
classes is a self-testing tangly mess that if you pull away one brick, the
whole lot comes crashing down, and is sufficiently non-functional as to make
testing impossible.

 put that another way: the set of objects which are inter-dependent to the
extent where you can get something useful to test requires so much
code-generation that you really aren't saving very much by even bothering to
remove even 98% of the classes.  the core - Window, Document, Node, Element,
NodeList, Attr etc. - is _that_ inter-related.

 2) i've gone well beyond the stage where "re-visiting" this code is something
that i would relish.  i'm happy with it.  it works.  it's a tangly mess of
spaghetti perl - my least favoured language - and i'd rather cut my arms off
and use my nose to type on keyboards for the rest of my life than get involved
in significant rewrites (no offense intended at your preferred choice of
code-generating language, alp :)

 i'd found myself doing the coding equivalent of holding my breath, waiting for
the tangly mess of interdependencies to resolve into something - _anything_
that i could consistently compile - and it was a good... ten or so days before
that happened.  the HTML elements i initially skipped; property getters and
setters i could skip [but couldn't test anything until they were added].

 so - if someone _else_ would like to split this work up into smaller patches -
_great_ - but count me out, big-time (except for advice).

 regarding the fork idea: i already have (by default):
  http://github.org/lkcl/webkit/tree/16401.master

 i needed a revision control system; i needed to be able to publish this to
people who are using it.  so far i've managed to do only about two svn
catching-up updates since august 2008 (am in the middle of another one, right
now) as they tend to take about three to four days, each.   that's not a good
situation for the people who are reliant on that code.

 so what's the alternative?

 well, we can sit and wait for someone else to come forward, someone with time
and resources of about two to three full-time months, who has the patience to
work through this and create smaller patches.

 ... but any corporation that looks at the tangly mess is much more likely to
go, "hmmm, that code on github works, let's just use it, as-is, instead".

and we've already _had_ one independent set of developers take a stab at
"simplifying" things, to the extent where i couldn't get involved, because too
much was missing - none of the pyjamas-desktop test suites or examples would
work.

> From the comments in this bug I get the impression that they indeed have a
> strategy, and you just don't agree with it.

 the strategy is to restrict language bindings tightly to the provably-broken
W3C standard, which _nobody_ - not one single browser technology group - has
_ever_ implemented as-is (not even webkit). _everybody_ throws in exceptions
and differences.

 so the "strategy" begins to look less like a "strategy" and much more like
goal-post-shifting hypocrisy.

 if one feature should not be added to GObject bindings because it is not in
the W3C standard, then _all_ features must be removed that do not fit into the
W3C standard.

 if one feature is allowed (contrary to the W3C standard) because it is
"useful" to some people, then to deny other features on some arbitrary basis
that it is "that guy whom we have no respect for, what's his name, i'm trying
to forget" who is recommending them is... what's the word... apartheid was
based on it... not racism... huh.  word escapes me.  the one where you have one
rule for one person or group, and another rule for another group.  
"discrimination".  that's the word i was looking for.

 so.  i want answers.  i want the evidence shown in the research to be
reviewed, and answers provided as to how the evidence presented fits in with
apple's strategy for webkit.  i've asked about seven times for a response, so
far.

> Which is naturally ok, as is the
> project maintainer's right to only accept code which implements *their*
> strategy.

 which is why i'm giving serious consideration to advocating the creation of a
webkit software foundation, where control is specifically taken _away_ from
apple as the sole and exclusive controller, and handed to a foundation which
has technical _and_ strategic merit for submissions at its core (the apache
foundation considered adding "strategic" merit to their charter, alongside
"technical" merit, after some discussions several years ago).

 but that's getting off-topic.

 *acch, tch*.  i just want to get on and for things to move forward, i'm fed up
with this stupid unnecessary blocking of progress.  i want people to be able to
use webkit in lots more free software projects, in lots more programming
languages and development environments than they are restricted to using at the
moment, that's the whole damn reason why i chose this work, the glib bindings,
in the first place - to open up webkit's strategic reach and to _help_ people.

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