[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jan 1 05:33:37 PST 2009
https://bugs.webkit.org/show_bug.cgi?id=16401
------- Comment #120 from lkcl at lkcl.net 2009-01-01 05:33 PDT -------
gustavo,
i do not know who you are, and so i let your unhelpful comments slide,
the first time (#78). now i cannot ignore them.
mark and i made an agreement to keep to technical issues - however,
unfortunately, there have been an increasing number of personal accusations
and unprofessional non-technical comments made as "justifications" for
blocking technical and strategic progress, and i cannot any longer keep
silent by ignoring them.
your comments are as unhelpful to the professional development and progress
of webkit glib dom bindings as mark's comments have been (except for the
technical advice comments he's been giving, which have been incredibly helpful
and valuable, and have helped the development and progress of the webkit glib
bindings enormously).
i will point out these things and then we will move on.
> So what if my project needs it? So what if pyjamas-desktop needs it? We need to
> figure out if it is the correct and best way of doing things for WebKit and the
> bulk of its users, not for your own pet project.
the description of the only full and complete project which uses the webkit
glib dom bindings as "my own pet project" is as insulting and unhelpful as
when mark also referred to it as "my own pet project".
i think it would be a good idea for you to publicly apologise for making
an accusation that i indulge in "pet projects".
also: where are the "other users"?
tell me where the "other users of webkit glib / dom bindings" are?
in essence what you're saying is that pyjamas-desktop is "not worth
respecting". it is "nothing".
what you are saying is that, having worked on the glib / dom bindings,
you are going to wait for _another_ project to come along (not
pyjamas-desktop) and you are going to listen to and respect them
enormously, and follow _their_ lead, _their_ advice...
... but not any advice or experience that comes from me.
is that right?
> I also feel you are being very unprofessional by implying all the time that the
> bindings you are pushing are a real project,
... and you're saying that the bindings are not???
(no of course you're not - but it just reads that way)
> while the Objective-C bindings must be a simple toy
to draw that conclusion is faulty logic. i said "i doubt whether any projects
that use the objective-c bindings hammer those bindings - make as _full_ use
of them - as pyjd makes use of the glib/gobject bindings".
i anticipate that someone with more experience than i in the objective-c
bindings will correct me, specifically in the areas of the usage of
"to string" conversion of elements, and in the areas of functionality of
HTMLAppletElement and HTMLEmbedElement, specifically the width and height
properties.
in the three short weeks in which i developed the webkit-glib bindings,
due to the nature of what pyjamas-desktop is and does,
pyjamas-desktop pushed pretty much _every_ single button there is to
push in webkit.
what other webkit-related projects do you know of that do that?
more to the point, what other webkit-related projects have you -
personally - got _specific_ and _direct_ experience with, that
involve the glib / dom bindings _and_ absolutely hammer the
stuffing out of the webkit-glib API?
> (and you have been doing that with other parts of the
> work, too).
i'm sorry to hear that you were able to draw that perception.
> The Objective-C bindings exist far longer, and have been used for
to give you a specific example: when i ported pyjamas-desktop onto
pykhtml / pykde, in under _six hours_ i encountered a very subtle bug
that has been present in KDE's python KHTMLPart bindings that has been
there for a _long_ time.
nobody - not _anyone_ - not even the developer of PyKHTML
(see http://paul.giannaros.org/pykhtml/) had spotted the bug.
as pyjd is effectively a widget set API, it _hammers_ the underlying
DOM model technology like you would not (and clearly do not) believe.
> much longer, and in more projects, so I can't see how you came to the
> conclusion that they are toyish.
i'm sorry to hear that you perceived that i have drawn this conclusion.
please consider correcting any impression that i have insulted and
disrespected the webkit developers by implying that i consider such
incredibly valuable work to be "a toy".
the objective-c bindings were an absolutely invaluable guiding light
in the development of the glib bindings, and i have an enormous amount
of respect for the technical ability of the developers who wrote that
code.
if i did not have so much respect for their code, there is no way that
i would have been able to have written the glib bindings in such an
incredibly short amount of time.
i would have been spending my time "objecting" to various absolutely
critical design decisions.
> > i'm sorry to have to be pointing these things out - i really wish i didn't
> > have to be the one to draw these conclusions. but anyone reviewing these
> > records will be able to draw the same conclusions, and likewise wonder why
> > you're being unreasonably obstructive.
>
> I draw the exact opposite conclusions. Why are _you_ being so unreasonable?
let's look at the word "un"-reasonable.
i have given "good reasoned" - reasonable - arguments for following the
lead of javascript, as a de-facto standard, rather than following one
which people _try_ to stick to (W3C) - and often fail.
those arguments have been ignored - and, instead of putting "reasoned"
and "reasonable" support for the dictats given, "un"-reasoned
"unreasonable" and logically unsupportable arguments have been given
instead, such as the one that you also support.
i am left somewhat amazed.
> I, for one, am against doing anything to the GObject DOM bindings that deviates
> from the standard. Where we deviate from the standard, it should be because
> we're following a proven de-facto standard,
hooray! i absolutely whole-heartedly agree with you!
_fantastic_!
now.
here's the thing.
the javascript bindings are a de-facto standard.
if you believe otherwise, please explain, providing examples and reasonable
justification, as to why you believe that the JS bindings are not a
de-facto standard.
if you agree with me that the javascript bindings are a de-facto standard,
please state so clearly.
> to keep compatibility,
hooray! yes! exactly! well done!
> not because
> your personal project needs it, so stop invoking your project as a parameter,
> pretty please.
once again, i have to point out several things:
1) describing pyjamas-desktop as a "my personal project" is insulting.
you will work out best how to apologise for saying so.
2) as the javascript bindings are a de-facto standard, and pyjamas-desktop
is a port of a javascript compiler which utilises javascript DOM bindings
and utilises pretty every single damn function and feature _of_ the
javascript DOM bindings, it is simple logic which leads me to be
advocating that the glib DOM bindings should support exactly the same
functionality:
pyjamas uses JS DOM ---> firefox, IE, safari provide JS DOM bindings
pyjd uses Glib DOM ---> XUL, PyKHTML, webkit provide ...
wait..... webkit _doesn't_ provide full DOM bindings, because
mark rowe and gustavo norono silva have absolutely no respect for
my opinion and expertise, believe that i am indulging in
"pet projecting", thus dismissing out-of-hand the entire project
and are going to "wait until someone else comes along with a
quotes non-pet quotes project".
in other words, gustavo norona silva, you don't trust me, and you
have no respect for my work.
... do you?
3) any use of a sentence which has the words "pretty please" in it, between
people who have _zero_ prior context or conversational interaction,
is wildly inappropriate for a technical forum.
ESPECIALLY one which will be a permanent record of the development of
a strategically important free software project such as this one.
so.
let's draw some conclusions, and let's rewrite what you've written,
justavo, so that it is more appropriate, and then i will respond to that.
> > however, for you to respond to reasonable justification for specific features
> > with "that could be a justification to put _anything_ into webkit" is
> > completely unprofessional.
> luke, i do not know who you are, and i have never spoken to you before,
> but the way that you are coming across does unfortunately look as
> unprofessional as you are saying that mark is being. i trust that you
> have good reasons for saying what you are, but surely there must be
> better ways to say it?
gustavo, thank you for responding - yes it's most unfortunate that this
highly strategically important free software opportunity is fast becoming
a bun-fight with an apple employee.
i realise that i'm not entirely at ease, sometimes, with communication of
highly technical issues: it often takes several rounds for me to get it
right, and i have had financial pressures to deal with that haven't helped
my frame of mind.
i apologise for this, and trust that you will make allowances.
yes there are very good reasons for pressing this point, and i seem to
be making a bit of a hash of explaining them. it doesn't help that mark's
attitude is an adversarial one, where he is working to "knock down"
rather than "cooperate".
it's this that is what i regard as unprofessional on his part, especially
as an employee and representative of the billion-dollar corporation called
"apple".
if i appear unprofessional, myself, it's because i am reacting out of
surprise, being completely caught off-guard at being treated so badly.
> regarding your rationale, i have to agree with mark that it _does_
> look as if it could be used to "put anything into webkit" as mark
> unfortunately puts it, and i would welcome a clarification from you
> on this. it certainly looks, on the face of things, like you are
> seeking the addition of a non-standard way to handle javascript calls,
> and if that is the case then mark is perfectly justified, in my
> opinion, in ensuring that that does not happen.
ah - i'm glad that you raised this, because it is most certainly _not_
the case that i am looking to "extend" the bindings "beyond" what
_existing_ de-facto standards already provide.
if you look beyond the shouting, you will see that "toString" and also
the properties of HTMLEmbedElement and HTMLAppletElement are part of a
"de-facto" javascript standard which has been "forced" onto webkit's
JS bindings, against apple's will.
my take on this is that once something is "forced" into the de-facto
Javascript bindings standard, it's really too late: it must _become_
part of that de-facto standard, and thus must become part of other
language bindings at all.
all or not at all.
and given that "not at all" is not possible, it must be "all".
to do otherwise is... well... you think of a word to describe it,
because i can't think of one that mark is willing to accept.
>So what if my project needs it? So what if pyjamas-desktop needs it? We need to
>figure out if it is the correct and best way of doing things for WebKit and the
>bulk of its users, not for your own pet project.
> in saying tha "pyjamas desktop needs it", unfortunately you haven't
> clearly said _why_ pyjamas-desktop needs these features. either that,
> or i am misunderstanding something, for which i apologise.
> We need to figure out if it is the correct and best way of doing things
> for WebKit and the bulk of its users, as well as for the project that
> you're working on. pyjamas-desktop and the invaluable work you've done
> in adding python bindings to the DOM model in pywebkitgtk is the only
> example that uses the webkit-glib dom bindings _right now_ but we need
> to think ahead.
yes, i absolutely agree with you - and that's exactly the perspective
from which i have been thinking. i did not think it necessary to emphasise
this, as i considered that, given that glib/gobject has multiple language
bindings autogenerators it would be implicit.... you get what i'm trying
to say, i hope - but i apologise for not being clear.
again, the real key here is in the fact that the javascript DOM features
make the javascript bindings an over-riding de-facto standard, and i believe
that it would be a serious mistake to attempt to make the W3C standard
the "lead".
pyjamas-desktop is just the one [and currently the only] example where,
if you do _not_ have webkit's glib DOM bindings be as identical as possible
to the webkit JS bindings, then pyjamas-desktop becomes _very_ very awkward
if not impossible to do.
however i do appreciate that it is _only_ an example, but to ignore that
example, instead of learning from the difficulties it has encountered,
_does_ strike me as being a little bit... odd.
surely, other projects (which don't yet exist!) should be learning from
this, and going, "hmmm.... that's really interesting - we should be watching
out for that, and making sure that apple _don't_ push the W3C standards
over-and-above the de-facto Javascript standard, because we might run into
the same difficulties that this guy lkcl is describing that his obscure
project we've never heard of is running into".
.... gosh, this is taking up an enormous amount of my time.
i'm going to leave it there, and i trust that you can see what i am
trying to do by rewriting what you've said, and i trust that you
can see how much easier it is to answer things in the rewritten
style.
no longer do i have to tiresomely "counteract" every single statement
and sentence that you make (except the one about javascript being
a de-facto standard! :)
instead i can focus on clarification of my points, and can clear
up any misunderstandings, and, through successive iterations we
work _together_ on the glib bindings, instead of working
_against_ each other.
yes?
i will leave it up to you as to whether you would like to continue
the rewrite, following the far-less-inflammatory style - one which
leaves an opening and an opportunity for discussion, rather than
one which i would not expect to come from an experienced free
software developer with an "@gnome.org" email address.
--
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.
More information about the webkit-unassigned
mailing list