Hej Chris! > I've now had time to have a read through the code in the "transport" > directory within the source tree. Firstly, I'm quite flattered by the > familiarity that I feel when reading through some of that code. :-P
You should be. There is a clear reason for that. > Looking at the code that I've written and the code that Sebastian has > written, it wouldn't be too hard for me to adapt my stuff to do what > Sebastian intends. That said, there's a problem that pops up if we do > try to group standard HTTP-style requests, hidden IFRAME requests and > XmlHttpRequest objects into a single class tree - the advantages of > inheritance disappear to a large degree. I do not understand what is going on, and I think Sebastian has to answer on that. Why are two people developing the same thing? Isn't that a total misuse of resources? Sebastian, what is going on? It kills the interest among people... I prefer inheritance and their are enough of obvious reasons for that. > For example, there's no way of firing off most events that are relevant > to XmlHttpRequest for the other types. Admittedly though, the other > types have advantages (such as being able to make requests to domains > other than the one the script is hosted on). That can be done in both but a little bit different. > Sebastian, it may be asking a bit much, but if you could tell me how you > want me to fit QxHttpRequest into the scheme of things, then I'll get to > work. Looking at what you've got in place, basically you want me to fit > it into the QxRequest-rooted tree, issue QxResponse objects on response > and use your new queuing system. This is a very good idea. Let Chris go on developing this part now! Sebastian, your monitoring is excellent, but stay with that and use the power of the group else people will run out of interest. > These aren't too hard, but: > > * Your new queuing system is timer-based, whilst mine is event-based. > Personally, I prefer (and would recommend everyone look into) > event-based queuing, as it tends to be easier to understand, easier to > debug and more efficient. Event based should be the choice to use least resources. > * (Please don't take this as anything but a suggestion / question) - > There are definitely advantages to having POST, GET and IFRAME requests > as options next to XmlHttpRequest, but should they really exist in the > same tree? A lot of XmlHttpRequest functionality can not be accessed > through the other methods, meaning that a large number of methods are > QxXmlHttpTransport-specific. I'm open to answers and supporting detail > here - as the great Larry Wall said, "be wary those who profess to know > the one true way". Good metaphor! > As always, please send all questions and feedback for prompt, thought > out responses. :-) > > Sebastian continues to do brilliant work - the fact that he's obviously > taken the time to look at my contribution is quite flattering and I hope > it's a trend that I can give reason for continuing. I think you are right. I think it is better that Sebastian tries to keep the group of users together. It is more than enough of work. It is just an advice based on long experience of opensource projects.. The best... Kent > Best regards, > > Chris > > Sebastian Werner wrote: > > Hi all, > > > > we think there were really great discussions on what features a new > > AJAX layer of qooxdoo should have. I have now started to create a new > > one, which is based on many ideas of Chris Ricks. Thank you again Chris. > > > > We have some other ideas added. We want a special request (QxRequest) > > and response (QxResponse) object to handle the data between the > > different communication layers in qooxdoo. Also we think to have a > > queue is great. But we think it is better placed outside the xmlhttp > > related stuff. We have done this in our new class QxRequestQueue. This > > class create instances of the class QxTransport which handles the > > wrapping to the different transport implementations. For example this > > could be the classical xmlhttp (QxXmlHttpTransport) or iframes > > (QxIframeTransport). > > > > This concept allows us to add new transport implementations easily if > > they appear on the horizon. > > > > There are some possibilities of Chris Ricks work missing. Like > > timeouts for example. This is something I think should be placed in > > QxRequestQueue, too. QxRequestQueue is somewhat basic currently and > > does no real queuing. > > > > As I have no more time to work on these classes before the final > > release of the next version of qooxdoo, this will be also the versions > > of the release. Afterwards we will continue the work. You are all > > invited to help. Chris, sorry, I hope I have not dis encouraged you > > with our plans and decisions. I would really like it, if you could > > help us, to extend and modify the newly existing stuff to your needs. > > > > For any further work, please keep the new code more prototype style > > and try to omit to send complete full-working classes. We should > > really discuss the additions and changes in detail before coding them. > > Thanks. > > > > Best regards, > > > > Sebastian > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Qooxdoo-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
