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

Thu Jul 30 05:55:58 PDT 2009

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

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-30 05:55:56 PDT ---
(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.

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