[Webkit-unassigned] [Bug 27435] adding XMLHttpRequest send idl language gobject

Mon Aug 3 14:15:47 PDT 2009

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

--- Comment #29 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-08-03 14:15:45 PDT ---
(In reply to comment #28)

> > #if (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT)
> >         void send(in DOMString data)
> >             raises(DOMException);
> > #else
> >         [Custom] void send(in Document data)
> >             raises(DOMException);
> > #endif
> > 
> > 
> > that's not altering the number of arguments; neither is it altering the
> > "defaults".
> 
> It's a function that is overloaded.  It has three variants, all mentioned in
> the specification for XMLHttpRequest.  One takes no arguments.  A second takes
> a string.  A third takes a document.
> 
> You've outlined that you ran in to problems exposing the variant that takes a
> Document and so opted not to do it.  That's fine.  What I'm looking for is an
> outline of the general approach to how overloaded methods will be dealt with in
> the bindings.  When we decide to expose send(Document) six months from now, how
> will we do so in such a way that it doesn't conflict with send() and
> send(DOMString)?

 ahh riiight - ok.  now i get it.

 correct me if i'm wrong, but what you're saying is that the concern is about
future interoperability.  which is something that i hadn't considered, being
perfectly at home with just going with whatever's there [as long as it's
equivalent].

 and, also - see below.  i think i'd kinda thought several steps ahead and
went, "naaah :)"

> It's worth noting that send isn't the only method on XMLHttpRequest that this
> applies to.  open is similarly overloaded:
> 
>   void open(in DOMString method, in DOMString url);
>   void open(in DOMString method, in DOMString url, in boolean async);
>   void open(in DOMString method, in DOMString url, in boolean async, in
> DOMString user);
>   void open(in DOMString method, in DOMString url, in boolean async, in
> DOMString user, in DOMString password);

 yehhs.  and 2DCanvasContext drawImage - 3 args, 5 args and 9 args.  and... i
think.... setAttribute... or was it setProperty...

> A similar approach would appear to be necessary here to prevent users from
> being required to provide all of the available arguments.

 i mentioned this before, but it's worth repeating in this context: in the
example of XMLHttpRequest.open i've found that simply passing in (method, url,
True, "", "") works.

 likewise, setAttribute (or setProperty) there's an extra argument: passing in
"" works.

 and it was mentioned based on the premise that trying, in c, to provide an API
which copes, in c, with multiple arguments, is a can of worms.

 also, given that it only those people with _really_ good reasons (such as
embedded systems) are going to be using the c interfaces direct, and that
everyone else will be using dynamic language bindings (vala, python, ruby)
those languages _do_ have "default" args capability, where the defaults can, if
the implementer decides, be reinserted - if required.

 so, not being funny or anything, but i think that the number of actual people
who end up using this c API - direct - is going to be _really_ small, falling
into these categories:

 * auto-language-binders (pywebkitgtk, adam's vala generator, ruby-binder)

 * embedded systems people

 * testers / unit-test implementors / demos / experiments
   (e.g. http://lkcl.net/webkit/main.c experiment)

 * other

the auto-generators, that's going to be like... one person per generator,
pretty much.   testers; small group.  embedded systems people who need speed: i
dunno, would they put up with API changes?  other: don't know.

the auto-generator group can take care of themselves, and, thanks to dynamic
language capabilities, they can adapt to re-present a consistent interface in
the face of underlying c API changes, and the users will be none the wiser.  

and with a decent set of unit tests (in an easy-to-use dynamic language), any
underlying c API changes can be caught _before_ they get to the users.

so - that just leaves embedded and other.

as i _am_ an embedded webkit-gobject API user, i can say (as a statistical
sample of one) that i'd be slightly annoyed if the API changed... but i would
put up with it.

the key reason is this: given that c is a statically-bound compile-time
language, i'd get compile-time errors, i'd grumble, i'd have to fix them - but
no harm would be done [unlike dynamic languages, where you _can't_ catch errors
except at runtime].

overall then, weirdly, there's a case for simply... not worrying about API
changes.  at all.

that and the combination of the empirical testing done so far [exposing and
using the longest of the available versions of the API] tends to support the
approach taken: ignore the overloads, use the longest version only, and let the
users of the API fill in the defaults.

i've been pretty much hammering virtually every corner of the gobject API
(except for 2D canvas) for what... eight months, now, and i can truthfully say
that i haven't encountered a DOM function yet that needed any exceptional
handling [to recreate the "lower-numbered" overloads, that is - i.e. defaults
do perfectly well].

drawImage with its 3, 5 and 9 args variants _might_ be one such function where
that principle goes belly-up, but the #16401 patch doesn't include SVG 2D
canvas - at all - so it's a moot point [but one to watch out for].

and, as this shows:

    https://bugzilla.mozilla.org/show_bug.cgi?id=502234

peter's accepting a patch to XULrunner to just expose the 3-variant of
drawImage, so that there's _something_ available - and to hell with the 5 and 9
arg variants :)  i.e. the images can always be resized / scaled another way.

> Given that DOM bindings are typically exposed as API, these are the sorts of
> issues that we need to be clear on from the start to avoid introducing
> confusion and API compatibility issues down the track.

 hope the above helps cover that.  short version: thanks ironically to both c's
strengths _and_ its limitations, i don't believe it will be an issue.

> > additionally, it can be seen that the function is mutually exclusive to its
> > Document counterpart.
> 
> It's not clear what you mean by this.

 sorry, it's a moot point / confusion on my part.  please disregard.

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