[Webkit-unassigned] [Bug 27434] adding necessary functions and properties to Document IDL gobject bindings
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Aug 7 12:34:10 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=27434
--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> 2009-08-07 12:34:08 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> > > even though the same information (the URL of a document)
> > > is exposed via the WebKit API in a different manner.
> >
> > in a manner which has knock-on complications for upstream development, yes.
>
> I don't understand what you mean by "upstream development".
ah, sorry.
> I suspect what you
> mean here is "it would affect my project". That is indeed unfortunate.
it would affect "the" project which i happen to be working on, yes.
as i explained when martin also used a personal pronoun to refer to some code
that i had written, i don't use personal pronouns to indicate claims of
ownership over code. it's a standard rule of software engineering: the usual
phrase to refer to it is "egoless programming".
much appreciated if you could say "the project that you're working on" rather
than "your project" etc. etc.
so, anyway...
i should explain [in the context of the project that i'm working on, which
happens to be the only active major project / test case / use case for these
bindings]
* pyjamas-desktop now has three ports: XULrunner, webkit and MSHTML.
* all three have python bindings.
* python-xpcom has read-only access to Document location properties
[through a weird read-only interface], and the nsIHTMLDOMDocument
interface appears to be TR-DOM2 only, with the location properties
themselves [if you follow the weird interface] are read-write:
http://www.oxymoronical.com/experiments/apidocs/interface/nsIDOMNSDocument
http://www.oxymoronical.com/experiments/apidocs/platform/1.9.2a1pre/interface/nsIDOMLocation
through which, it's possible to get and set location, in exactly the way
that's intuitively expected.
* MSHTML's COM interface has read-write access to Document.location:
http://msdn.microsoft.com/en-us/library/aa752596(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa703641(VS.85).aspx
through which, it's possible to get and set location, in exactly the way
that's intuitively expected.
* webkit's javascript interface has read-write access to Document.location
* webkit's gobject interface has a bun-fight going on over its format,
with several options being presented and discussed. [one is read-only
identical access to what the other competitor language bindings
provide]
* webkit's gtk interface has a non-W3C-DOM-spec-compliant read-write interface
so - with the option that has the least "knock-on complications for upstream
development", the pseudo-code would look like this:
def getLocation(document):
return document.location
and then, to get or set them, you just... do so.
that's pretty simple, huh?
with the method which you're recommending, _all_ upstream implementors
[language bindings developers, users of the language bindings, or just people
who use gobject c bindings direct] would have to do something like this:
def getLocation(document):
if systemtype == 'mshtml' or systemtype == 'xulrunner':
return document.location
else # heeere we go....
class LocationWrapperToDealWithStupidAPIDecision:
def __init__(self, document):
self.wrapped_document = document
def get_hash(self):
return
webkit_web_frame_get_location_hash(self.wrapped_document)
def set_hash(self, value):
......
.....
.....
.....
return LocationWrapperToDealWithStupidAPIDecision(document)
do you see how pointless and ridiculous that is?
do you also appreciate how much work it is?
now multiply it up by the number of developers of language bindings.
> However, I don't think it's a reasonable approach for you to write a patch,
> start using it in your own project
[correction: using it in a project which is entirely free software,
on which i happen to have chosen to contribute to]
> before it has been accepted upstream, and
> then insist it be accepted in the form you provided because you're using it in
> that form and you don't want to adapt to changes that are requested.
ah. the clue here is "that are requested". there's an assumption that i
agree with the changes requested. as you've discovered: sometimes i do,
sometimes i don't. if i agree, i'll get on with it immediately, as you've
noticed. if i don't, i'll say so.
what i _won't_ do is simply make changes "that are requested" just _because_
they have been requested.
it's up to you to convince me that the changes requested don't have adverse
consequences and/or don't force on people [times however many gobject language
bindings autogenerators etc.] an extra workload. and, as i'm working on the
only project which is _actively_ dependent on these bindings, it gives me some
active experience and a direct feel for what's needed, which i believe is very
relevant.
so.
in this case, the changes "that are requested" have a nasty set of knock-on
implications that will burden absolutely everyone using them.
not only that, but i really don't see what the problem is. if people _need_
the write-capabilities to Location right now, right this second, then, yes,
they'll use the [stupidly-named, non-W3C-compliant] webkitgtk+ functions.
if they don't, they can use the temporarily-made-read-only W3C-compliant
versions. or the temporarily-not-working-as-writeable W3C-compliant ones.
> > > My point is simple: I don't see the value in exposing an incomplete DOM binding
> > > for this property since there is an existing means of retrieving this
> > > information. It doesn't seem worth the mess of #if'ing up the IDL files and
> > > the confusion that would result from users who expected the exposed properties
> > > to behave in the standard manner.
> >
> >
> > ahh, but mark, it was you who turned down the review on the simple
> > approach, which was to just have the Document.location property made
> > available and be done with it, on the basis that the custom functions
> > can be added later.
>
> A simple approach that had similar issues to the current patch: it exposes
> what is at best a confusing subset of the bindings.
well, you can't have it both (all) ways, right now. which would you prefer -
make up your mind! :)
> > so, now i think we've covered the possibilities, we have three approaches to
> > take. which is it going to be?
> >
> > 1) make life damn awkward for upstream development
> >
> > 2) "complicate" the IDL file (but protect users from the consequences)
> >
> > 3) "clean" IDL, make things easy for upstream developers, with known
> > consequences and an upgrade / development path which can be fixed
> > at a later date?
>
> Since you've injected hyperbole and omitted clarity from this list
make up your mind which you would like! if i provide sufficient detail so as
to be clear, you accuse me of wasting time! :) ok, that's being silly, but it
has a grain of truth in it.
the above pseudo-code helps clarify what 1) is. 2 lines of code (or not even
that) or a ridiculous wrapper class which "normalises" the DOM API, redirecting
from what would otherwise be a decent (albeit limited) and above all *standard*
API, into some code that was added in a decision by the webkitgtk+ developers
to avoid writing the gobject bindings.
> it's not
> clear to me what each of the options corresponds to. I'll restate what I feel
> the situation is:
ok. good idea.
> The patches so far expose a subset of the Location bindings that allows one to
> access the location of a Document.
ack.
> The WebKit APIs expose existing means of
> accessing the location of a document.
yep. and changing it, too.
> I have not seen a good argument for why
> adding #if's to the IDL files in order to expose functionality that is already
> available via other means is a good thing. Exposing full bindings for Location
> does seem like a good idea, but you've expressed reluctance to do that at this
> time.
yes. although, the amount of time spent just discussing this somewhat
laboriously does lead me to wonder if i should reconsider that.
but - what's stopping me from doing that is that it will have knock-on
implications for the CodeGeneratorGObject code, because anything that's
"Custom" has to be special-cased right now [because many of the "Custom"
functions and properties are either skipped, or the "Custom" property ignored
entirely].
yet more changes and additions to an already complex generator, through
non-webkit-standard controlled process, just seems like a truly bad idea, to
me.
> That seems fine to me, since as I've mentioned the information is
> already exposed using other API.
ok - it seems fine to you, because you're not the one who has to write the
"wrapper" classes, upstream (in every single programming language which
utilises the gobject bindings) to re-normalise the webkit-gobject API to one
which matches the W3C specification _just_ for what will turn out to be a
relatively small period of time.
this is an _interim_ measure we're discussing, not a permanent one, after all.
so.
implications 1) : webkit is quotes nice and simple quotes, but everybody
_else_ has to do a lot of work.
implications 2) : read-only on Location properties and read-only on
Document.location is quotes complicated in the IDL file quotes yet is also
simple for upstream developers. but it has the advantage that in between the
time when the gobject patches are being landed and when somebody writes the
necessary gobject custom location code, upstream developers are protected from
nasty consequences.
implications 3) : read-write on Location properties is quotes simple for the
IDL file quotes and also simple for upstream developers, but has the nasty
consequence that if the upstream developers try to set location properties...
nothing happens. fortunately, this will only be for a short period of time
(until someone writes the necessary gobject custom location code), but even
so...
1) is definitely not an option i would deem acceptable [and, if there _were_
any other developers other than myself and yorba doing language bindings to
gobject...] 2)... *shrug*. 3)... *shrug*.
also, for completeness, there's this:
4) - i write the gobject custom bindings _before_ landing the gobject patches:
nnnnno. there's been enough svn-history / information been lost as it is,
already, through the use of an external non-webkit-based repository
(github.org) in the maintenance of the gobject bindings.
5) other [anyone else got any ideas?]
so - 2 3 or 5 - you choose, i don't mind which.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list