[Webkit-unassigned] [Bug 27435] adding XMLHttpRequest send idl language gobject
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jul 30 04:56:37 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=27435
--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> 2009-07-30 04:56:35 PDT ---
(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.
--
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