[Webkit-unassigned] [Bug 27434] adding necessary functions and properties to Document IDL gobject bindings

[bugzilla-daemon at webkit.org]

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





--- Comment #22 from Mark Rowe (bdash) <mrowe at apple.com>  2009-08-03 10:26:35 PDT ---
(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".  I suspect what you
mean here is "it would affect my project".  That is indeed unfortunate.

However, I don't think it's a reasonable approach for you to write a patch,
start using it in your own project 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.

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

>  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 it's not
clear to me what each of the options corresponds to.  I'll restate what I feel
the situation is:

The patches so far expose a subset of the Location bindings that allows one to
access the location of a Document.  The WebKit APIs expose existing means of
accessing the location of a document.  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.  That seems fine to me, since as I've mentioned the information is
already exposed using other API.

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