Hi Derell, thanks for your remarks.
> Hmmm... Transport is a low-level concept that I feel should be abstracted. > The interface that the user sees should be consistent regardless of the > transport in use. Although there are plenty of problems with the old > implementation, that's one area I think it really got right. I agree that transport is low-level and should be abstracted. That's why we introduced bom.request.* classes that share an XHR like interface. Classes found in io.request.* build on this abstraction, are qooxdoo-like and offer more convenience (headers, events, states, parsing). What we don't abstract (yet) is the type of transport. If you compare the API docs, you see that while the interface is the same and most events and properties share semantics, there are still differences that unfortunately cannot be hidden. Take the status property for example. For Xhr the transport supports the HTTP status code meaning that the service can embed fine grained meta information in a request's response. For Jsonp on the other hand the HTTP status code itself is unknown and status has a slightly different meaning (that is 500 when the callback was not called). Yes, on a higher level "callback not called" and "404 not found" can mean the same thing. But what if it doesn't? Just image the user expects a specific status code and later enables cross-origin support. We want the user to be aware of the differences. In other words: We don't want to create the illusion that transports are interchangeable without any side effects. > If the user has to explicitly select a transport, then how is there a > default? Furthermore, if the interface for different transports is different, > I don't think you can have a default. Both transports have a common denominator (see AbstractRequest). One could argue that it's best to use the inherently more complete Xhr if possible and only switch to Jsonp if indicated by the user. This should work as long as you don't rely on Xhr only methods such as setAccept. > 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? Regards Tristan ------------------------------------------------------------------------------ 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
