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]> 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]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
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
