Hey Derrell,
I have to agree with Tristan. We have talked about that and that was one of the
main reasons for me to get a new transport layer to get rid of that
abstraction. What I really don't like about that abstraction is, that we simply
can't abstract it so we should not pretend to do so. Why do I think that?
The error handling of the script transport is not working very well. As far as
I know, you won't get any error at all in IE and Opera. But thats working fine
with XHR. So within the abstraction, we have an error event which usually gets
used by the app developer. So now switching one flag to cross domain will
disable that error event which is nothing you would expect as developer if you
don't know what your doing and what transports are used in that abstraction.
Additionally, independent from the transport layer, qooxdoo has a very specifiy
API which I like. So having an API that magically changes on the switch of a
property is hard to document and in my opinion not easy to use. So in the end,
if you want to use it the right way, you need to get in touch with the
restrictions anyway and need to understand why they are there.
Regards,
Martin
Am 20.05.2011 um 14:21 schrieb Derrell Lipman:
On Fri, May 20, 2011 at 08:13, Derrell Lipman
<[email protected]<mailto:[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
<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
