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

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-24 02:23:09 PDT ---
(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.

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