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
