[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 #21 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-08-03 01:19:22 PDT ---
> >  please correct me if i'm wrong, but it sounds like you're saying that the
> > webkit API is set in stone, and that anyone wishing to make use of webkit must
> > live with that, even if it doesn't do what's actually needed.
> > 
> >  ... but i doubt very much that that's what you're saying.
> 
> That would be a stupid thing for me to say.  Thanks for suggesting that it was
> what I said.

 this comes across as a sarcastic comment, which i am sure you did not intend
it to be.

 i did no such thing: i respectfully requested clarificaiton, which you've
kindly provided, below.  i apologise for giving the wrong impression.

> You were arguing that it is vitally important to expose this incomplete DOM
> binding immediately, 

 yes.  the read-only information is vital, and is in real-world usage, today.

 the writing can wait.


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


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

 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?

1) isn't acceptable.  2) i can live with.  3) i believe is the best, pragmatic
workable path.

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