Bug 27435 – adding XMLHttpRequest send idl language gobject

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Luke Kenneth Casson Leighton]

this is part of a series of splits of #16401 into smaller patches
as part of an agreement recommended by david.

for several months, discussions went unanswered regarding adding this absolutely essential feature.  after a thorough investigation, it turns out that in #16401 around the comment c170 to c180 mark, a comment made by me to adam did result in adam picking up my advice, and this resulted in reviewers actually responding and agreeing with my original suggestions that:

* send be allowed to take DOMString for now

* this be revisited after landing.

at long last, thanks to the involvement of yorba, the argument made by reviewers that LANGUAGE_GOBJECT be removed is at an end.

[Luke Kenneth Casson Leighton]

Created attachment 33064 [details]
allows DOMString to be passed to XMLHTTPRequest send, in gobject bindings

[Eric Seidel (no email)]

Shouldn't it be defined(LANGUAGE_GOBJECT) and LANGUAGE_GOBJECT ?

Othewise this looks fine.

[Mark Rowe (bdash)]

Comment on attachment 33064 [details]
allows DOMString to be passed to XMLHTTPRequest send, in gobject bindings

I think this raises an important issue that needs to be considered: what is the strategy for handling functions that use overloading based on number of arguments or argument types in these bindings?  If this method is exposed as API, how will the variants expecting no arguments or a Document be exposed?  Due to the fact that DOM bindings are typically considered to API I think this warrants discussion prior to this single method being selected.  The maintainers of the GTK+ port would be good people to be involved in that.

[Xan Lopez]

(In reply to comment #3)
> (From update of attachment 33064 [details])
> I think this raises an important issue that needs to be considered: what is the
> strategy for handling functions that use overloading based on number of
> arguments or argument types in these bindings?  If this method is exposed as
> API, how will the variants expecting no arguments or a Document be exposed? 
> Due to the fact that DOM bindings are typically considered to API I think this
> warrants discussion prior to this single method being selected.  The
> maintainers of the GTK+ port would be good people to be involved in that.

Since the baseline language for the GObject bindings is C we'll have to create one function for each variant of the methods like this one, basically. Since this does not seem to be very common I think it's perfectly fine if we just hand-write that when it's needed (this kind of fix-up/glue when doing bindings is relatively common in my experience).

[Mark Rowe (bdash)]

(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 33064 [details] [details])
> > I think this raises an important issue that needs to be considered: what is the
> > strategy for handling functions that use overloading based on number of
> > arguments or argument types in these bindings?  If this method is exposed as
> > API, how will the variants expecting no arguments or a Document be exposed? 
> > Due to the fact that DOM bindings are typically considered to API I think this
> > warrants discussion prior to this single method being selected.  The
> > maintainers of the GTK+ port would be good people to be involved in that.
> 
> Since the baseline language for the GObject bindings is C we'll have to create
> one function for each variant of the methods like this one, basically. Since
> this does not seem to be very common I think it's perfectly fine if we just
> hand-write that when it's needed (this kind of fix-up/glue when doing bindings
> is relatively common in my experience).

Ok.  It sounds like we'll need to come up with some means of dealing with these overloaded functions.  I don't think it's appropriate to #if the IDL file to expose only a single variant in this case given the potential of this showing up as API, and thus limiting our options, before the issue is resolved.

[Luke Kenneth Casson Leighton]

(In reply to comment #2)
> Shouldn't it be defined(LANGUAGE_GOBJECT) and LANGUAGE_GOBJECT ?
> 
> Othewise this looks fine.

 ahhh, yes - the patch was forward-ported from nearly a year ago so i missed that one, thanks for catching it.

[Luke Kenneth Casson Leighton]

(In reply to comment #3)
> (From update of attachment 33064 [details])
> I think this raises an important issue that needs to be considered: what is the
> strategy for handling functions that use overloading based on number of
> arguments or argument types in these bindings?  If this method is exposed as
> API, how will the variants expecting no arguments or a Document be exposed? 
> Due to the fact that DOM bindings are typically considered to API I think this
> warrants discussion prior to this single method being selected.  The
> maintainers of the GTK+ port would be good people to be involved in that.

 it's a good point that you raise

 as the gobject bindings can, with care and about 100 lines of restructuring code per port, be utilised in _any_ port, i would suggest that the discussion be opened to all ports not just the GTK+ port.

 if you want to do it the "clumsy" way [and least disruptive way], you can see how little code is required, from this:
   https://bugs.webkit.org/show_bug.cgi?id=27430

 so, i would suggest that this be discussed on webkit-dev [and will assume that that's reasonable, and will open the discussion there].

 in anticipation that the discussion will take the path of "least resistance", and having been involved in this _and_ in XULrunner's DOM bindings, and so having a significant amount of exposure to the issue that you raise, i'll re-submit the patch with the corrections from #27435#r2.

[Luke Kenneth Casson Leighton]

Created attachment 33325 [details]
corrections to #ifdefs as per r2 comment

[Mark Rowe (bdash)]

Comment on attachment 33325 [details]
corrections to #ifdefs as per r2 comment

Marking as r- for reasons previously noted.

[Sam Weinig]

Is it really appropriate to expose XMLHttpRequest to GObject?  I would assume better options exist for making network requests in GTK environments.

[Luke Kenneth Casson Leighton]

(In reply to comment #10)
> Is it really appropriate to expose XMLHttpRequest to GObject?

 of course it is.

 there are so many reasons why it's a good idea and so many as to why it's a bad idea to not have it, i can't even begin to list them all.

 not least of them is "xulrunner, MSHTML _and_ KHTML already provide access to XMLHttpRequest via language bindings, why on earth would you want to make webkit language bindings that are any different??"

>   I would assume
> better options exist for making network requests in GTK environments.
 
 [don't forget that GTK+ is _not_ the only port that can take advantage of the glib / gobject bindings.  i _do_ keep emphasising this and you _do_ keep making statements that seem to not take this into account.]

 that just means writing alien code, across multiple languages.  why do you want to make peoples' lives more difficult?

 example:

 to port pyjamas to pyjamas-desktop, all i had to do was convert javascript
 to python, which is a process that literally took only around... two days,
 to convert the 1000 or so lines of hard-coded javascript into approx-1000
 lines of python.

 line-for-line, the python is identical (near-as-damnit) to the javascript
 from which it was ported.

 this then reduces the amount of testing overhead of the pyjamas-desktop
 implementation, because the API, apart from a few wrinkles, is absolutely identical in python as it is to javascript across thousands of functions.

 [why do you think i've been pushing so hard to get you guys to accept gobject bindings as a peer to the de-facto javascript-driven standard, rather than the as-yet-not-commonly-implemented HTML5 standard? it's because it makes life absolute hell if it isn't exactly the same as it can be made ]


 

 example code:

 from HTTPRequest.py module, here's the javascript version:

    def asyncPostImpl(self, user, pwd, url, postData, handler,
                            returnxml, content_type):
        pdlen = str(len(postData))
        JS("""
        var xmlHttp = this.doCreateXmlHTTPRequest();
        try {
            xmlHttp.open("POST", url, true);
            xmlHttp.setRequestHeader("Content-Type", content_type);
            xmlHttp.setRequestHeader("Content-Length", pdlen);
            xmlHttp.onreadystatechange = function() {
                if (xmlHttp.readyState == 4) {
                    delete xmlHttp.onreadystatechange;
                    var localHandler = handler;
                    var response;
                    var status = xmlHttp.status;
                    if (returnxml)
                        response = xmlHttp.responseXML;
                    else
                        response = xmlHttp.responseText;
                    handler = null;
                    xmlHttp = null;
                    if(status == 200) {
                        localHandler.onCompletion(response);
                    } else {
                        localHandler.onError(response, status);
                    }
                }
            };
            xmlHttp.send(postData);
            return true;
        }
        catch (e) {
            delete xmlHttp.onreadystatechange;
            var localHandler = handler;
            handler = null;
            xmlHttp = null;
            localHandler.onError(String(e), "");
            return false;
        }
        """)


and this is the python version (with, obviously, the onreadystatechange coming out as a separate function, not a lambda as it is in the javascript, above):


    def onReadyStateChange(self, xmlHttp, event, ignorearg):
        try:
            xmlHttp = get_main_frame().gobject_wrap(xmlHttp) # HACK!
        except:
            pass # hula / XUL
        if xmlHttp.readyState != 4:
            return
        # TODO - delete xmlHttp.onreadystatechange
        localHandler = handlers.get(xmlHttp)
        del handlers[xmlHttp]
        responseText = xmlHttp.responseText
        status = xmlHttp.status
        handler = None
        xmlHttp = None
        # XXX HACK! webkit wrapper returns 0 not 200!
        if status == 0:
            print "HACK ALERT! webkit wrapper returns 0 not 200!"
        if status == 200 or status == 0:
            localHandler.onCompletion(responseText)
        else :
            localHandler.onError(responseText, status)


    def asyncPostImpl(self, user, pwd, url, postData, handler,
                            return_xml, content_type):
        mf = get_main_frame()
        xmlHttp = self.doCreateXmlHTTPRequest()
        if url[0] != '/':
            uri = mf.getUri()
            if url[:7] != 'file://' and url[:7] != 'http://' and \
               url[:8] != 'https://':
                slash = uri.rfind('/')
                url = uri[:slash+1] + url
        # try:
        if mf.platform == 'webkit':
            xmlHttp.open("POST", url, True, '', '')
        else:
            # EEK!  xmlhttprequest.open in xpcom is a miserable bastard.
            # won't take the last 3 optional args.
            #xmlHttp.open("POST", url, True, '', '')
            xmlHttp.open("POST", url)
        xmlHttp.setRequestHeader("Content-Type", content_type)
        xmlHttp.setRequestHeader("Content-Length", str(len(postData)))

        if mf.platform == 'webkit':
            mf._addXMLHttpRequestEventListener(xmlHttp, "onreadystatechange",
                                         self.onReadyStateChange)
        else:
            mf._addXMLHttpRequestEventListener(xmlHttp, "load",
                                         self.onLoad)
        handlers[xmlHttp] = handler
        xmlHttp.send(postData)

        return True

        #except:
            #del xmlHttp.onreadystatechange
        handler = None
        xmlHttp = None
        localHandler.onError(str(e))
        return False



so you can see, it's pretty much identical.

are you _truly_ telling me that i must rip that all out, because there is something quotes "better" quotes in some GTK library somewhere?

do those quotes "better" quotes libraries support asynchronous POST and asynchronous GET?

are they _exactly_ the same as the API available in webkit?

are you saying that you want to force pyjamas-desktop - and anyone else who wants to do XMLHttpRequest in vala, java, perl or anything else that wraps the gobject bindings - to _each_ write their own version of XMLHttpRequest?

you _got_ to be kidding.

[Luke Kenneth Casson Leighton]

Comment on attachment 33325 [details]
corrections to #ifdefs as per r2 comment

ehh?  sorry, what reasons?  if you look closely at the comments, mark, it's been discussed (by xan) and i concur with xan's assessment; eric's review comment is satisfied - what reasons are you referring to?

[Alexey Proskuryakov]

Exposing XMLHttpRequest to anything but JavaScript sounds like a weird idea to me, as well.

[Alexey Proskuryakov]

Exposing XMLHttpRequest to anything but JavaScript sounds like a weird idea to me, as well.

[Luke Kenneth Casson Leighton]

(In reply to comment #14)
> Exposing XMLHttpRequest to anything but JavaScript sounds like a weird idea to
> me, as well.

truly, it isn't.  yes it may be an alien concept, but it's a standard, and
standards are really important.

plus, second-guessing what people _might_ come up with, and (don't take this the wrong way, ok) then criticising them for doing so, isn't a developers' job.  not being funny or anything, but i don't think restricting progress and
possibilities is part of a free software development team's remit!


think about the cost of compiling up webkit, for windows, which is a truly dreadful proposition, i can tell you.  by focussing on it non-stop, once, i managed to compile webkit - badly - for win32 in _only_ 8 days.  other people have tried and failed in two months.

now, on top of that dreadful prospect, you want to _add_ to their burden by forcing them to compile yet _more_ libraries?

remember that posix-compliant systems have it easy (macosx, gnu/linux, freebsd)
because you have macports, .deb, rpm, etc. which automate the build process.  but under windows, users simply aren't either provided with pre-built libraries or are simply not geared up to compile them, themselves.  especially as the dependencies, in free software projects, typically run to tens of megabytes.



_then_, and i'm sorry to be labouring the point but this really is quite important that XMLHttpRequest be added to gobject bindings, it would be a real serious mistake not to include it, there's libsoup.

allow me to explain.

by including XMLHttpRequest, you've made it possible for example to compile an application written in java (GWT), python (pyjamas) or ruby (rubyjs / RWT) to be compiled to javascript BUT also the SAME application possible to be run DIRECT using the direct bindings (pyjamas-desktop plus pywebkitgtk).

you can get a glimpse of that from the code snippet in https://bugs.webkit.org/show_bug.cgi?id=27435#c11 and you can run the
pyjamas jsonrpc example online, http://pyjs.org/examples/jsonrpc/output/JSONRPCExample.html
and then, if you compile and install pywebkitgtk according to the
instructions i've given, and the "full" patched version of #16401,
you can then run the *same* example application *UNMODIFIED*
under pyjamas-desktop.

how?

because you're contacting the SAME jsonrpc service using both the
javascript-based version in a browser or the pywebkitgtk-based version
(using webkit as the engine, or xulrunner if you prefer).

so, that _is_ very weird - to be utilising a web service even on a
desktop, but it _does_ have advantages, in that it forces the programmer
to subdivide their appplication along MVC-like lines, and it has the
advantage that, if desired, the "service" can actually be run on a
faster system, or pushed out to "cloud" computing, whilst leaving
the front-end still installed locally (as python, in the case of
pyjamas-desktop apps) _and_ then you can still obviously have people
using web browsers to access those same externally-hosted services.

but - leaving that distinct advantage aside, there's libsoup.

so, you don't _like_ the idea of having to install a web service?
fine - you can "bypass" the need for a web service, by using
soup_server_new(), and then passing that soup server instance
_into_ webkitgtk!

which is very very cute.

in this way, you no longer need apache or any other web server
infrastructure of any kind, because you have cut out the middle
man by using libsoup.  libsoup _is_ the web server ( without the
web server, so to speak ).

_and_, if you design the "service" carefully (e.g. using simple and
elegant jsonrpc glue) you can _still_ use the _exact_ same service
code running locally (using libsoup) as can also be provided via
apache or other remote web server infrastructure!

so, again, this should serve to illustrate that there are some really exciting and intriguing possibilities that make app developers lives much much easier, through the simple step of including XMLHttpRequest.

lastly, it has to be said: the whole concept of ripping out javascript and replacing it _entirely_ with python or other dynamic language is itself utterly alien to many people, but once you get used to it, it's like a "woww" lightbulb moment, "i can do whaaaat, now?"

once you're over that mental hurdle, use of XMLHttpRequest is just a natural step.

[Christian Dywan]

Luke,

trying to read these excessive rants in bugzilla comments is tedious. :)

In short, pyjamas is a 1:1 mapping of javascript interfaces to python syntax and that's why you want XMLHttpRequest exposed in the DOM bindings.

I agree with Alex and Sam here. The goal of WebKitGTK+ is a GTK+ style interface, we have curl, libSoup, libgdata and numerous other network libraries for the job. I don't see any advantage in exposing XMLHTTPRequest. If you want to use javascript, use javascript, not python.

Incidentally, why did you mention repeatedly that GObject bindings be useful to other ports? As far as I'm aware no port other than WebKitGTK+ is planning on using these same bindings.

[Luke Kenneth Casson Leighton]

(In reply to comment #16)
> Luke,
> 
> trying to read these excessive rants in bugzilla comments is tedious. :)

 mmmm, christian, i see a smiley so i know your intentions are good, here  there are simply so _many_ good reasons that it's difficult to know which ones you will accept, so i gave as many as i had time for and left it at that.

 unfortunately, i can see that there were _so_ many that you simply haven't the  viewpoint or ... something, i don't know what, to incorporate the answers.  and, i'm too literal-minded to know when _not_ to answer a question.

 so, i know it's a bit hit-and-miss, dealing with me, but your patience
 is really appreciated.  there's a long road ahead, and still so
 much more work to be done.

 
> In short, pyjamas is a 1:1 mapping of javascript interfaces to python syntax

 pyjamas is a stand-alone python to javascript compiler and also a DOM-based U.I. widget set, yes.  by using the compiler, you get to develop web 2.0 apps that will run inside all major web browsers.

 pyjamas _desktop_ is the python free software equivalent of Adobe AIR and silverlight, where the javascript is entirely ripped out and replaced with 98% the _exact_ same python U.I API source code that was compiled to javascript for the browser-only version!

 and, that U.I API _includes_ XMLHttpRequest, because the DOM has that as part of the W3C standard.


> and that's why you want XMLHttpRequest exposed in the DOM bindings.

 [correction in viewpoint, christian: what _i_ want has nothing to do
  with the discussion.  i prefer to think in non-egoistic terms, and
  much prefer to discuss matters in non-personal terms.  otherwise
  the mistake might be made of a disagreement being confused with
  a personal insult.  which is happening rather a lot, here, so
  it's best that that be avoided.  so - rewriting: ]

> and that's why you believe that XMLHttpRequest should be exposed
> in the DOM bindings.

 it's just one justification, from experience, yes.  that it's the only webkitgtk project actually _utilising_ the DOM bindings fully and to the utmost extent should lend some weight to the proceedings, i trust.

 repeating in part what i've written above: because it would be absolutely ridiculous just to have to reimplement XmlHttpRequest in terms of an extra dependency, _just_ for webkit, when all the competitor python technology - XulRunner via python-xcpom, and MSHTML via python-win32com, _and_ even python-khtml, all have XmlHttpRequest, comfirming to the W3C standard provides.

 you _really_ want webkit to be the exception?

> I agree with Alex and Sam here. 

 agreement with their viewpoint, which is one of "i don't understand why" doesn't constitute a technical argument to leave out something that someone _else_ is telling you is important.



> The goal of WebKitGTK+ 

 ah.  the goal of _webkitgtk+_.  but these are gobject bindings.  gtk != gobject, you know that.

 so, the goal of the _webkitgtk+_ project has a narrowed perspective and viewpoint, one which is non-inclusive of other goals and other projects.  bearing that in mind, let's carry on...

> is a GTK+ style
> interface, we have curl, libSoup, libgdata and numerous other network libraries
> for the job.

 i've answered this from several perspectives (in what you rather unfortunately refer to as a rant, oh well, can't have everything), and i'm happy to reiterate and add to them here, in bullet-form:

 * the webkitgtk+ perspective is a narrowed perspective on a narrowed
   perspective.  by not taking into consideration other factors,
   of _course_ it looks like XMLHttpRequest is redundant.

 * those libraries are not part of the DOM interface.

 * if you _exclude_ part of the DOM, you are in violation of the
   W3C standards.

 * win32 user find it hard enough to install webkit and its
   dependencies, let alone any other extra libraries, and the build
   process is a nightmare.  XMLHttpRequest is already part of the
   DOM, it's there, if users use it, they don't _need_ to go through
   a world of pain.

   summary: XMLHttpRequest is a _standard_.

 * MSHTML and XULrunner already _have_ XMLHttpRequest, why would you
   want to "dumb down" webkit??
 
 not least, there's the simple fact that by _not_ adding XMLHttpRequest, you're _forcing_ people into your way of thinking.

 with XMLHttpRequest added, people can _choose_ to use it, or _choose_ to use libSoup, curl, libgdata etc.

 it's no skin off your nose if XMLHttpRequest is added, but if you _don't_ add it, you're forcing people down _your_ path.

 put that another way: just because _you_ can't see it's useful doesn't mean that other _people_ can't see that it's useful.


> I don't see any advantage in exposing XMLHTTPRequest.

 i've outlined several advantages!

 and several warnings.  one of which, perhaps the most important and simplest is, that by leaving out XMLHttpRequest, you will be violating the W3C standard.


> If you want
> to use javascript, use javascript, not python.

 no, that's not going to work (and also misses the point).  think it through, christian.

 as you have said that i am making "rants" i will not tell you why unless you explicitly ask, because if i "tell" you, you might not listen to the answer.

 so - why would javascript access to XMLHttpRequest be completely inadequate, to python (or gobject) bindings?

 think it through.

 as a clue: try running pyjamas apps and compare them to running the same app under pyjamas-desktop.  if you do that, the answers will become clear.


> Incidentally, why did you mention repeatedly that GObject bindings be useful to
> other ports?

 because with a little care, and about 200 lines of code per port [at a guess], they can be.

 this will allow those ports to avoid the pain that the gobject bindings have gone through.  by the simple matter of #include <gobject.h> _not_ i repeat _not_ #include <gtk.h>.  gobject != gtk, you know that.

 think about it: after the complete fiasco of #16401, do those ports _really_ want to go through the same process?

 and, also, do you _really_ want yet another complex bit of perl to maintain?

 i think, to be honest, that the whole language bindings system needs to be looked at, and replaced with something like mozilla's XPCOM.  this would make everyone's lives a whooole lot easier.

 ok.  enough.

[Christian Dywan]

(In reply to comment #17)
> (In reply to comment #16)
> > Luke,
> > 
> > trying to read these excessive rants in bugzilla comments is tedious. :)
> 
>  mmmm, christian, i see a smiley so i know your intentions are good, here 
> there are simply so _many_ good reasons that it's difficult to know which ones
> you will accept, so i gave as many as i had time for and left it at that.

A good way to reason about code is, to me, use cases. When I say 'rant' I'm referring to your tendency to drift into political aspects I'm not interested in. Plus your tendency to turn one statement into a paragraph.

> > In short, pyjamas is a 1:1 mapping of javascript interfaces to python syntax
> 
>  pyjamas is a stand-alone python to javascript compiler and also a DOM-based
> U.I. widget set, yes.  by using the compiler, you get to develop web 2.0 apps
> [...]
>  and, that U.I API _includes_ XMLHttpRequest, because the DOM has that as part
> of the W3C standard.

From my understanding, XMLHTTPRequest is a javascript specific standard. If you can point me to an article or paper clarifying this I'd like to read it.

> > I agree with Alex and Sam here. 
> 
>  agreement with their viewpoint, which is one of "i don't understand why"
> doesn't constitute a technical argument to leave out something that someone
> _else_ is telling you is important.

I understood both of them have the same thinking that the interface in question is javascript specific and not useful beside that, which I agree with unless I see otherwise. That does not mean I would ignore following arguments.

> > The goal of WebKitGTK+ 
>  ah.  the goal of _webkitgtk+_.  but these are gobject bindings.  gtk !=
> gobject, you know that.

„Incidentally, why did you mention repeatedly that GObject bindings be useful to
other ports? As far as I'm aware no port other than WebKitGTK+ is planning on
using these same bindings.“

> > a GTK+ style interface, we have curl, libSoup, libgdata [...]
>  * those libraries are not part of the DOM interface.
>  * if you _exclude_ part of the DOM, you are in violation of the W3C standards.

To my understanding DOM  bindings mean access to and inspection of the structure of a webpage. That doesn't include graphics, videos, scripting or network at all. If you think this is a violation of the specification, as noted above. please explain where this is stated.

>  * win32 user find it hard enough to install webkit and its dependencies

That's no argument. Win32 users, as in application users, won't compile anything. And for developers WebKit itself is, as complex as it is, hard to build. But most small libs aren't. And they don't have to do it in the first place, binaries are usually available, even for WebKitGTK+.

>  * MSHTML and XULrunner already _have_ XMLHttpRequest, why would you
>    want to "dumb down" webkit??

I don't personally think "XUL has it, so we need it" by itself is a good reason. Use cases are what matters. Of course as argument 10 of 10 it's fine.

>  it's no skin off your nose if XMLHttpRequest is added, but if you _don't_ add
> it, you're forcing people down _your_ path.

Be aware that any interface will be expected to be supported. As a maintainer you do care how your project is used.

> > I don't see any advantage in exposing XMLHTTPRequest.
>  i've outlined several advantages!
>  and several warnings.  one of which, perhaps the most important and simplest
> is, that by leaving out XMLHttpRequest, you will be violating the W3C standard.

Please refraim form repeating yourself mutiple times. Once is clear enough.

> > Incidentally, why did you mention repeatedly that GObject bindings be useful to
> > other ports?
>  because with a little care, and about 200 lines of code per port [at a guess],
> they can be.

„they can be“ sounds contrieved. I know Qt, Mac and neither of the Win32 ports will. Theoretically the clutter port might want to, which I don't know.

[Mark Rowe (bdash)]

Comment on attachment 33325 [details]
corrections to #ifdefs as per r2 comment

Marking as r- based on the comments from several reviewers and contributors.

[Luke Kenneth Casson Leighton]

(In reply to comment #19)
> (From update of attachment 33325 [details])
> Marking as r- based on the comments from several reviewers and contributors.

mark,

please refrain from making premature judgements.  this matter has not been fully discussed satisfactorily.

[Luke Kenneth Casson Leighton]

(In reply to comment #19)
> (From update of attachment 33325 [details])
> Marking as r- based on the comments from several reviewers and contributors.

additionally, look at https://bugs.webkit.org/show_bug.cgi?id=27435#c2

what does it say?

it says "this looks fine" [other than a correction required, which i did].

then, you raise a [completely unnecessary, as you will see, eventually] point, which has nothing to _do_ with the bugreport.

so - the matter is not closed.

[Maciej Stachowiak]

Luke asked me to comment. Here's my thoughts:

1) It's reasonable for a DOM binding to choose to export XMLHttpRequest. One plausible use case: the bindings user may want to write some code that participates fully in the browser's loading model, including security, progress notifications, cancel on end of page load, etc. It might be possible to do that otherwise, but it doesn't seem simple to me. Also, some native platform APIs, for example Cocoa Touch on the iPhone, have found the XHR model, quirky though it may be, to be fairly convenient and have added their own native imitation.

2) I think whether to support XMLHttpRequest (which has lots of quirky behaviors) as public API should be up to the port maintainers. For the GObject bindings, I think it should be up to the WebKit/Gtk+ port maintainers, as the WebKit/Gtk+ port is the only one that is currently planning to export GObject bindings, so it impacts logic and maintainability of their public API. If other ports decide they want to do so, then they should have a say as well.

3) Since this involves handling the weird case of multiple methods with the same name in C, maybe XHR is not the best choice to tackle in an early phase of this project. I'd rather see a simple bindings script, and a consensus on the general design for overloaded methods in C.

4) Important point to consider about overloaded methods: it's possible for methods in the Web platform to start out having a fixed number of arguments, but later gain optional arguments or overloading. It's also the case that sometimes the IDL files are edited and reordered. To support overloading in C, I think it's important to make a design that's future-proof against future changes to the IDL. One possible way: sort methods by number of parameters, and add number variants to the ones with more parameters. I don't know if this has been done already or not but there should probably be some agreement on the right approach before moving forward.

Overall, it might be better to resubmit this patch once a bindings generator script that can handle at least basic cases has been submitted, and once input has been gathered from WebKit/Gtk developers on whether this makes sense in the public API.

For what it's worth, I think it might make sense to make XMLHttpRequest part of the ObjC DOM bindings as well.

Side not for Luke: marking a patch as r- doesn't indicate the matter is closed, just that the patch needs revision according to the reviewer.

[Luke Kenneth Casson Leighton]

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Luke,
> > > 
> > > trying to read these excessive rants in bugzilla comments is tedious. :)
> > 
> >  mmmm, christian, i see a smiley so i know your intentions are good, here 
> > there are simply so _many_ good reasons that it's difficult to know which ones
> > you will accept, so i gave as many as i had time for and left it at that.
> 
> A good way to reason about code is, to me, use cases. When I say 'rant' I'm
> referring to your tendency to drift into political aspects I'm not interested
> in.

 they're not "political".  they're part of the responsibility and duty of being a free software developer, to take into consideration the impact of the code that's been developed, and any burdens and costs that are imposed on developers.

 that's not "political", that's common sense.

 if you're "not interested" in that, then that _automatically_ disqualifies you from putting any input into this process, because you're not taking your responsibilities and duties seriously.


> Plus your tendency to turn one statement into a paragraph.

 well, that's because there is so much involved.  i don't know how much you can cope with, and what you can't, so i err on the side of caution, and provide as much information as i can.

 this is, after all, a review and a discussion.


> > > In short, pyjamas is a 1:1 mapping of javascript interfaces to python syntax
> > 
> >  pyjamas is a stand-alone python to javascript compiler and also a DOM-based
> > U.I. widget set, yes.  by using the compiler, you get to develop web 2.0 apps
> > [...]
> >  and, that U.I API _includes_ XMLHttpRequest, because the DOM has that as part
> > of the W3C standard.
> 
> From my understanding, XMLHTTPRequest is a javascript specific standard.

 javascript specific?  of course it isn't.

 * in the MS case, it's provided as an Active-X control (via DCOM).  thus, it's open to visual basic, python, c, c++, and any programming language that can get at DCOM (including java).

 * in the kde case, it's provided as part of the KHTML codebase, with interfaces to c++, python and javascript.

 * in the mozilla case, they have XPCOM, and there is also what they call the "native" access, to the underlying c++ code.  XPCOM provides a boat-load of options.

 so it's most definitely _not_ a javascript-specific standard.


> If you
> can point me to an article or paper clarifying this I'd like to read it.

 i think it will be more informative to you if _you_ do the research, but,
 seeing as you ask, allow me to put you on track.

 if you use google, put in "java xmlhttprequest example".  take a look
 at the number of results there.

 SEVEN HUNDRED THOUSAND results, for "java xmlhttprequest example", alone.
 this one's difficult to assess because the variations and permutations
 and uses are so numerous.  there's ways to use java with DCOM on MSHTML;
 there's.... ich :)

 google "xpcom xmlhttprequest" - 25,000 results.

 "calling a web request in c++ using XMLHTTPRequest":
   http://forums.mozillazine.org/viewtopic.php?f=27&t=1280475
  
 "xpcom callbacks"
   http://www.nabble.com/xpcom-callbacks-td1984119.html

 "debian packaging of xulrunner-1.9"
    http://packages.debian.org/sid/xulrunner-1.9-dbg
  includes XML extras such as XMLHTTPREQUEST


 google "xmlhttprequest msxml2.xmlhttp" - FOUR HUNDRED AND FIFTY THOUSAND
 results.

 some guy's random blog on how to use XMLHttpRequest from VB.NET:
   http://radio.javaranch.com/balajidl/2006/01/18/1137606354980.html

 in it he says, quote:

 "I already knew how to do it with Java Servlet or PHP or VB or C++ or even VB.NET window application. I can also do it with AJAX but XMLHttpRequest expects you to have well-formed html.(say xhtml) I want to call MSHTML from ASP.NET with VB.NET as backend."


 that should be enough for you to be getting on with - i'm sure that you could find some more - sufficient to your satisfaction.

 please come back with the results of your findings.
 

> > > I agree with Alex and Sam here. 
> > 
> >  agreement with their viewpoint, which is one of "i don't understand why"
> > doesn't constitute a technical argument to leave out something that someone
> > _else_ is telling you is important.
> 
> I understood both of them have the same thinking that the interface in question
> is javascript specific and not useful beside that, which I agree with unless I
> see otherwise.

 great! https://bugs.webkit.org/show_bug.cgi?id=27435#c11

 fantastic - the discussion is over, because it _is_ useful.

 i'm glad that you agree, it will save vast amounts of time, not having to go through all the other points.



> > > The goal of WebKitGTK+ 
> >  ah.  the goal of _webkitgtk+_.  but these are gobject bindings.  gtk !=
> > gobject, you know that.
> 
> „Incidentally, why did you mention repeatedly that GObject bindings be useful
> to
> other ports? As far as I'm aware no port other than WebKitGTK+ is planning on
> using these same bindings.“
> 
> > > a GTK+ style interface, we have curl, libSoup, libgdata [...]
> >  * those libraries are not part of the DOM interface.
> >  * if you _exclude_ part of the DOM, you are in violation of the W3C standards.
> 
> To my understanding DOM  bindings mean access to and inspection of the
> structure of a webpage. That doesn't include graphics, videos, scripting or
> network at all. If you think this is a violation of the specification, as noted
> above. please explain where this is stated.

 ok - additional standards (extensions included).  i tend to forget that.

> >  * win32 user find it hard enough to install webkit and its dependencies
> 
> That's no argument.

 why?

> Win32 users, as in application users, won't compile
> anything.

 precisely.

 placing the burden randomly onto the developers.  if the developers don't "second-guess" what the users might want to do, then they are stuck.


> >  * MSHTML and XULrunner already _have_ XMLHttpRequest, why would you
> >    want to "dumb down" webkit??
> 
> I don't personally think "XUL has it, so we need it" by itself is a good
> reason.

 think about this scenario:

 a developer has an application that uses XULRunner (XPCOM).  it works, but it's ... too big, too slow (whatever).  so the developer wishes to port it to webkit.

 they're using XMLHTTPRequest (see google search numbers, above).  they turn to webkit-gobject because it is most equivalent to XPCOM, and they find... what?

 they find that this discussion resulted in XMLHttpRequest being _actively_ excluded from webkit-gobject.

 they then look at webkit-objc, and find that... wtf, it's included???  but they want a gnu/linux system not an opendarwin one or a macosx one.

 then they look at webkit-DCOM bindings, and they're even _more_ confused, because _that_ has XMLHttpRequest as well.

 then they look at the cost of writing a replacement asynchronous look-alike library.


 now multiply that up by the number of different bindings to gobject: python, perl, java, ruby, vala, and pure c.

 so for those developers who _do_ use XMLHttpRequest, to save development time and to "fit in" with an existing de-facto standard, you want to impose a MASSIVE overall cost of development by _actively_ removing access to XMLHttpRequest, for no good reason that i have yet to see.



> Use cases are what matters.
 
 ah - good!  because there _is_ a use case - pyjamas-desktop.

  
> >  it's no skin off your nose if XMLHttpRequest is added, but if you _don't_ add
> > it, you're forcing people down _your_ path.
> 
> Be aware that any interface will be expected to be supported.

 out of three hundred gobjects, the burden to the maintainers of one more - that has been _proven_ to work, thanks to pyjamas-desktop - is absolutely tiny.

 if you can't cope with 0.33% extra workload, you're doing the wrong job.

 plus, as i consider it my responsibility and duty to maintain pyjamas-desktop, on behalf of the users, that kinda makes it my responsibility and duty to support XMLHttpRequest in webkit gobject bindings.

 and all the other three hundred or so gobjects as well.

 so, you're asking if you expect it to be supported, the answer's yes!

 

> As a maintainer
> you do care how your project is used.

 not being funny or anything, but with respect, i don't see any evidence of that.   as in i see quite a large number of people treating pyjamas-desktop as if it didn't exist, or was completely worthless.

 that perspective has got to change.  pyjamas-desktop _is_ the use-case, _is_ the test platform.

 i don't see any other webkitgtk+ projects that are using webkit-gobject to the massive extent that pyjamas-desktop does.  not even yorba.  yorba's vala bindings use a _fraction_ of the capabilities of webkit-gobject.

 and, to remind you: webkit-objc _already_ have objc-bindings to XMLHttpRequest, as do the webkit-DCOM bindings.

 so they're _already_ supported, there.


> > > I don't see any advantage in exposing XMLHTTPRequest.
> >  i've outlined several advantages!
> >  and several warnings.  one of which, perhaps the most important and simplest
> > is, that by leaving out XMLHttpRequest, you will be violating the W3C standard.
> 
> Please refraim form repeating yourself mutiple times. Once is clear enough.

 well, with respect, and tongue in cheek, once doesn't seem to be sinking in! :)  but seriously - sorry about that, there is so much to cover, it seems like such a simple question "why bother adding XMLHttpRequest when there are 'perfectly good' networking APIs available" with such a high cost-benefit ratio in _favour_ of including XMLHttpRequest that i'm having difficulty not overloading you with answers.  and, as a result, i forget, even in one message, of what i've already said.


> > > Incidentally, why did you mention repeatedly that GObject bindings be useful to
> > > other ports?
> >  because with a little care, and about 200 lines of code per port [at a guess],
> > they can be.
> 
> „they can be“ sounds contrieved. I know Qt, Mac and neither of the Win32 ports
> will. Theoretically the clutter port might want to, which I don't know.

 .... and future ports might want to, as well.  on that basis, you have even _more_ cost to add to the burden for developers.

 overall, the sheer cost in developer time which the use of an existing de-facto standard will save (even if it's a bit weird) _dwarfs_ the cost of maintaining it.  which is tiny.  _and_ you have to actively go out of your way to add in code into the CodeGenerator to remove references to XMLHttpRequest!


 now.

 that all aside, there is one additional rather important point that needs to be considered, and it's this:

 is the use of other networking libraries, bearing in mind that they will need to be asynchronous as well as synchronous, thread safe?

 think that through.  i'll take the liberty of helping out, by raising some key points to consider:

 * who is going to write some test code that proves that each and every networking library, synchronous and asynchronous, will work with webkit-gobject in a thread-safe manner?

 * what happens if it's discovered that there needs to be a cooperative locking mechanism between glib/gobject networking libraries or other networking libraries, and webkit-gobject?

 * who is going to write the code that fixes up webkit to work with each and every single networking library?

 * even if it does work, who is going to write the tutorials and the HOWTOs to explain to people how to use each and every single networking library?

 
 with respect, you can count me out of helping on this one, because i decided over ten months ago, now, to utilise XMLHttpRequest and to support that, for pyjamas-desktop.

 it works very well.

 and, because it's part of the webkit infrastructure, all of the callbacks and the threading etc. just "work".  even when you have python bindings.  of course, i discovered quite early on that you _must_ call gobject_threads_init(NULL) not gdk_threads_init(NULL) but once i'd got over that speedbump, everything just... worked.

 so.

 if you want to support the use of external networking libraries, please go ahead and do so, and do the legwork involved in proving that the theory - the THEORY - that you have will work.

 but until you've proven that theory, might i ask if you could not impede the progress of the real-world use-case which is actually _using_ XMLHttpRequest.  successfully.

[Luke Kenneth Casson Leighton]

(In reply to comment #22)
> Luke asked me to comment. Here's my thoughts:
> 
> 1) It's reasonable for a DOM binding to choose to export XMLHttpRequest. One
> plausible use case: the bindings user may want to write some code that
> participates fully in the browser's loading model, including security, progress
> notifications, cancel on end of page load, etc. 

 hmm, that hadn't occurred to me.  in pyjamas-desktop, as with the most common usage of XHR, the API uses onload (onreadystatechange) to detect load success, HTTP errors and timeouts, but that's about it.

 ... it never occurred to me that users might want the other features :)

> It might be possible to do that
> otherwise, but it doesn't seem simple to me. Also, some native platform APIs,
> for example Cocoa Touch on the iPhone, have found the XHR model, quirky though
> it may be,

 [ asynchronous APIs usually are.  people don't like them.  i believe that it's only because of javascript, where you really _have_ to use async, that XHR has got as far as it has]

> to be fairly convenient and have added their own native imitation.

 iiinteresting....

> 2) I think whether to support XMLHttpRequest (which has lots of quirky
> behaviors) as public API should be up to the port maintainers. For the GObject
> bindings, I think it should be up to the WebKit/Gtk+ port maintainers, as the
> WebKit/Gtk+ port is the only one that is currently planning to export GObject
> bindings, so it impacts logic and maintainability of their public API. If other
> ports decide they want to do so, then they should have a say as well.
> 
> 3) Since this involves handling the weird case of multiple methods with the
> same name in C, 

 i've outlined the answer to this already, but i realise that it's difficult to find things in amongst the sheer number of issues being discussed, so i'm happy to repeat it here.

 i've found, from experience, that simply taking the longest of the multiple-methods is perfectly acceptable, and works very well.  that having been said, there actually aren't that many "multiple methods".

 in the case of XMLHttpRequest.open(), putting '', '' as the user and password arguments has been proven to be adequate, and proven to work.


> maybe XHR is not the best choice to tackle in an early phase of
> this project.

 it's already _been_ tackled - successfully - _months_ ago, maciej! :)

 that's the really weird thing that people don't seem to appreciate, here.  pyjamas-desktop _works_.

 the only things missing are 2D Canvas (all of it), execution exceptions (ExecState) and ENUMs (all of them).


> I'd rather see a simple bindings script, 

 *lol* :)  so would a ton of other people, maciej :)

> and a consensus on the
> general design for overloaded methods in C.

 as i've mentioned, i've worked through this already, and have a proven working first version that covers preeetty much all the angles.  please note - the key here is _proven_.

 so, whilst a general design is being discussed, perhaps the _proven_ working design might meet with approval, first, and it might actually turn out to be unnecessary to do any further work.


> 4) Important point to consider about overloaded methods: it's possible for
> methods in the Web platform to start out having a fixed number of arguments,
> but later gain optional arguments or overloading. It's also the case that
> sometimes the IDL files are edited and reordered. To support overloading in C,
> I think it's important to make a design that's future-proof against future
> changes to the IDL. One possible way: sort methods by number of parameters, and
> add number variants to the ones with more parameters. I don't know if this has
> been done already or not but there should probably be some agreement on the
> right approach before moving forward.

 honestly, there _really_ haven't been that many.

 there has in fact only been one: initKeyboardEvent.   that's literally the only one, so far.   and, the only reason that _that_ is there is, ironically, a conscious violation of the W3C standard, to add support for the Alt-Gr key!

 over the past ten months i've done what... three major svn updates to keep this work current.

 i've found in that time that the code-generator simply... creates more arguments.

 what _has_ proven to be awkward is of course the addition of extra features such as [Reflect] which of course are simply catch-up - but even that, when i added it last week, required a patch of... at most 25 lines.

 and what also has proven to be awkward is the reshuffling of the IDL, RGBColor turning from a long into a DOM object, for example, and a few other additions.  EventTargetNode disappearing was damn awkward.

 but... extra arguments?  naah, not a problem.   defaults?  explained already: that can be catered for by providing the "longest" version [currently only one function!] and then requiring that the callers, from c, provide all the arguments themselves.

 that's easy enough to do in c, and, once it's done, it's easy enough for bindings such as python to then "re-provide" defaults using a wrapper.  if they can be bothered.  which, in the case of pywebkitgtk, i can't be. [because there are so few cases].



> Overall, it might be better to resubmit this patch once a bindings generator
> script that can handle at least basic cases has been submitted,

 :) *shakes head and smiles*  maciej - it already _does_ :) 


 ... i know i've asked and advised this a number of times, but has anyone on the webkit team actually tried to _use_ #16401, pywebkitgtk or pyjamas-desktop,  or at the very least, have they tried this replacement GtkLauncher main.c:

 http://lkcl.net/webkit/main.c

 i do keep gently reminding people that it would be a real eye-opener to see what's possible.

 and, it would also put webkit developers and reviewers into a much better position with respect to discussions.

 after all, if you've never actually _seen_ what you're reviewing, how can it be said that you're able to make well-informed decisions?



> and once input
> has been gathered from WebKit/Gtk developers on whether this makes sense in the
> public API.

 i'm quite happy to let the webkit/gtk developers take over making decisions _if_ they get up-to-speed on what's actually involved.

 at the moment, there's yorba's project (which they've had to abandon due to time constraints) and there's pywebkitgtk with pyjamas-desktop on top of that.

 that's it.

 _none_ of the webkit/gtk developers have come to me and said, "i compiled that GtkLauncher main.c example and i have some questions", and i also haven't seen any questions asking how pywebkitgtk or the full-patched #16401.master is compiled.

 not being funny or anything but that leaves them in a seriously under-informed position to make any kind of contribution or to make any kind of serious decisions about the public API.

 and i believe that that's the primary reason why we're having such a roaring bun-fight over these bindings, simply because people haven't actually _used_ them.

 so that rather unfortunately leaves me as pretty much the only person with any experience, expertise and authority on these bindings, and i don't mind saying that i'm well aware that i'm a pain in the neck, mostly _because_ i'm already ten steps ahead, and moving on to projects which actually _deploy_ these bindings, in the field.

 so - _yes please_, take over, for goodness sake, but - for goodness sake, get up to speed, first.


> For what it's worth, I think it might make sense to make XMLHttpRequest part of
> the ObjC DOM bindings as well.

 oh?  they're not already??  ah.  christian, my apologies, i thought that they were.


> Side not for Luke: marking a patch as r- doesn't indicate the matter is closed,
> just that the patch needs revision according to the reviewer.

 ahh. good.  i wasn't aware of that [the first bit].  i'm of course aware that the patch is considered to need revision.

 the unfortunate thing that i've found is that much of what i'm saying and raising is going completely over peoples' heads ["rant" etc.] - and then they get frustrated and angry with me because they think i'm not answering their points!

 so, to get them to actually pay attention - _actually_ pay attention - i've been slowly upping the ante, using the available tools [yet they _still_ don't answer the issues!]

 all quite daft, really, and we could really do without it.

 if the reviewers can promise to actually take into consideration the issues that i raise, then all the silliness can be gotten rid of.

 i don't mind honest mistakes, and i'm happy to admit mistakes and apologise for them, and move on, but i _do_ mind accusations that i haven't answered issues.

 so - we're going to be at this for a long time, so it makes sense to actually take into consideration issues raised, so that the only project actively utilising all of the available features of these bindings at the moment actually continues to be useful to its users.

[Mark Rowe (bdash)]

(In reply to comment #24)
>  honestly, there _really_ haven't been that many.
> 
>  there has in fact only been one: initKeyboardEvent.   that's literally the
> only one, so far.

XMLHttpRequest::send.

[Luke Kenneth Casson Leighton]

(In reply to comment #25)
> (In reply to comment #24)
> >  honestly, there _really_ haven't been that many.
> > 
> >  there has in fact only been one: initKeyboardEvent.   that's literally the
> > only one, so far.
> 
> XMLHttpRequest::send.


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

i realise that the number of times that the reason for making this change have been explained many times, but i also realise that the sheer complexity and number of issues involved is overwhelming people, so i am happy to patiently repeat the reasoning behind this modification.

* "standard" send(Document data) was found to be difficult to implement

* it was found that a TextDocument was required

* creation of a TextDocument was required

* due to insistence that constructors not be allowed (as a javacript-ism)
  a "special" function had to be added to WebKitWebFrame, to allow the
  gobject bindings to have a text document (see https://bugs.webkit.org/show_bug.cgi?id=27430)

* for unknown reasons, adding webkit_web_frame_create_text_document()
  resulted in segfaults.  therefore it was removed.

* too much time was being wasted investigating.

* a simple decision was made: re-enable the "old" XMLHttpRequest.send
  function.

* problem solved.


so, as can be seen, that has nothing to do with the number of arguments to functions, nor does it have anything to do with default values to functions in the IDL.

additionally, it can be seen that the function is mutually exclusive to its Document counterpart.

[Luke Kenneth Casson Leighton]

(In reply to comment #23)
>  they then look at webkit-objc, and find that... wtf, it's included???  but
> they want a gnu/linux system not an opendarwin one or a macosx one.
> 
>  then they look at webkit-DCOM bindings, and they're even _more_ confused,
> because _that_ has XMLHttpRequest as well.

 sorry, please disregard these two paragraphs: maciej pointed out that webkit-objc doesn't _have_ XMLHttpRequest [but puts forward a use-case argument in favour of adding it].

 i apologise for assuming that webkit-objc and webkit-DCOM would automatically have XMLHttpRequest.

[Mark Rowe (bdash)]

(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > >  honestly, there _really_ haven't been that many.
> > > 
> > >  there has in fact only been one: initKeyboardEvent.   that's literally the
> > > only one, so far.
> > 
> > XMLHttpRequest::send.
> 
> 
> #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)?

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);

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

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.

> additionally, it can be seen that the function is mutually exclusive to its
> Document counterpart.

It's not clear what you mean by this.

[Luke Kenneth Casson Leighton]

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

[Luke Kenneth Casson Leighton]

https://bug459452.bugzilla.mozilla.org/attachment.cgi?id=342670

ScrollIntoView is another one.