On Fri, May 20, 2011 at 08:13, Derrell Lipman <
[email protected]> wrote:
> You mention, as a counter-argument, the status codes. The set of HTTP
> status codes, although intended to be specific to HTTP, is broad enough in
> meaning that it can be equally-well used for the other transports. Really,
> only the first digit is important, although there are a few well-known codes
> that should always mean the same thing (e.g., 404). The first digit tells
> the severity of the error, with 4 being "sorry, I can't do it, and nothing
> you do over there at the client will allow me to do it." Other first digits
> mean "transient error", etc. You've probably looked at the HTTP spec, so
> you're likely familiar with all of this. In any case, it's general enough
> that adopting it for generic transport is reasonable, and allows the user a
> common interface where he specifies what he wants to do ("I want to talk to
> a remote machine at this URL, and I have form fields that need to be sent"),
> not how it should be done ("use IframeTransport").
>
> 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.
For me, personally, I wouldn't need any abstraction because I know this
stuff well enough. For newer users, and those (even experienced) users not
intimately familiar with the intricacies of transports (particularly with
cross-domain requests), the abstraction seems to me to make a lot of sense.
Cheers,
Derrell
------------------------------------------------------------------------------
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
