Hello, My shiney new qooxdoo app has grown up to 2,000 lines in the last several weeks, this framework is super! (Just "diving in" seems to have been the way to go for me....)
I could never get my back-end, even when reduced to not much more than a "Hello World", response back into Qooxdoo. Yes, I changed various fields in the config and other files, in short, everything I could think of at least 10 times. THEN I tried WebSockets - and I was off to the races. Not much code. It "just works" and seems fast and powerful, BUT I'm no expert and I'm rather over my head with the security issues and such - I'd like to put off these types of things until after I have established a basic working "circuit". Now I'm looking around and finding that there are some very interesting, and economical, solutions that use WebSockets (starting to pop up, it would seem). I'm not sure how to weigh the advantages of Websockets over HTTP but I thought I'd give this a good go before returning to knocking my bloody head against the wall trying to using HTTP again. (Even a minimalist HTTP WebFramework like Sinatra seems to me to be about 80% "bloat" that I don't need.) Any comments on WebSockets being the future, a canard or whatever fully appreciated... *but here's the situation:* The company I am the most impressed with (Pusher) has various Serverside tools and I think I'm home free as these folks are also heavy into Ruby. ON THE CLIENTSIDE however they are documenting that I "should" put *this into my HTML:* to have the benefit of their JavaScript support. I've really searched the Qooxdoo manuals and this forum (there's a good 2009 thread considering what could be done) but I'm not sure how things have landed, or what it is I'm dealing with. The pusher library seems small enough, and I'm desperate enough to consider bringing it into Qooxdoo one method at a time, particularly if this would be a decent way to do things, but I fear things are changing rapidly and this would get me into stuff I don't want to be overly involved with unless I must... BTW, what I find particularly intriguing about the WebSocket approach is that the Server can trigger events and "push" to the Client side. In our particular usage niche this seems to have a lot of "power" although I don't have any immediate need for it. Otherwise, it seems faster and more efficient, and there is expert talk of a huge percent savings in overall traffic vs polling. The pusher site is here: http://pusher.com/docs/javascript_quick_start if anybody is interested. Thanks in advance for any comments, Sincerely, GKoller -- View this message in context: http://qooxdoo.678.n2.nabble.com/Including-a-JavaScript-Library-and-WebSockets-tp6939273p6939273.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
