On Fri, May 20, 2011 at 07:26, Tristan Koch <[email protected]> wrote:
>
> > Yeah, I think we lose valuable functionality by removing the higher-level
> construct, leaving only the low-level access to the transport.
>
> By functionality you mean automatically choosing an appropriate transport?
>
Kind of. I don't think the user should have to know the details of
transports to select one. I think, instead, they should specify what they
want to do, and the transport should be chosen for them.
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").
Those are my thoughts.
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
