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

Mon Jul 27 05:29:23 PDT 2009

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

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-27 05:29:21 PDT ---
(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.

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