Derrell,
I totally agree. Maybe we are wrong and need to put something on top. The good
thing is, we still can with the current architecture. :)
Regards,
Martin
Am 23.05.2011 um 12:58 schrieb Derrell Lipman:
Tristan and Martin,
Thanks for providing the rationale behind your decisions. It seems to me to be
counter to qooxdoo's design to leave such a low-level decision as which
transport to use up to the user, but I guess we'll find out by the questions on
the ML how confusing that is for people. From a technical viewpoint, your
rationale is valid, so I'll be interested in the results of this experiment as
far as typical user ease of use.
Derrell
On Mon, May 23, 2011 at 04:31, Tristan Koch
<[email protected]<mailto:[email protected]>> wrote:
Am 20.05.2011 um 14:21 schrieb Derrell Lipman:
> So it occurs to me that even the status code could be abstracted. If the
> low-level status values are different depending upon transport, then there
> could be a generic status code that says that the request succeeded, failed
> due to something permanent, or failed due to a transient error. (There may be
> a few more generic errors that could be added.) Then, if one wanted to know
> more details, one could request (a) what type of transport was used, and (b)
> the transport-specific status code that was returned.
I think the kind of abstraction you describe above can in parts be found in
io.request.AbstractRequest. First, there are different error events. Also, we
have the (pseudo) property state which can be anything of unsent, opened, sent,
loading, success, abort, timeout, statusError.
In other words, the common user does not need to know the specifics about the
transport's error conditions, neither does he usually need to query the status
and need to know which number is erroneous.
Speaking of the status code itself. The status code is abstracted in the sense
that there is no strict mapping to the HTTP status. bom.Jsonp inherits from
bom.Script. bom.Script, which is commonly referred to as the script transport,
can't determine the response's HTTP status. In bom.Jsonp however, we can detect
when the callback is not called, meaning the the response was unexpected. So we
assign a status of 500, even though we don't have a real HTTP status available.
If we abstracted the type of transport used, a user could confuse status 500
with a real HTTP status.
Apart from the status code or the error event mentioned by Martin, I think it
gets really messy when you consider cross domain request. Modern browsers
(except IE9) [*] support cross domain XHR. So lets imagine we abstract the type
of transport and have a crossDomain flag similar to the one in the old
transport layer. When set to true, we need to figure out how to send
cross-domain requests for each browser. Browsers support cross-domain XHR will
use XHR, others the script loader. This would mean we use different transports
depending on the platform! Moreover, cross domain XHR only works when the
backend is configured to return adequate headers. So, in theory, if we wanted
to have a decent automatic detection of the transport, we would need to query
the backend somehow prior to sending the request (and use the script loader
when those headers are missing). I like magic, but thats a bit too much of it
for my taste.
Hope you follow our reasoning.
Regards
Tristan
[*] IE9 does support cross domain XHR, but not with the XmlHttpRequest host
object.
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
qooxdoo-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
<ATT00001..txt><ATT00002..txt>
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
