Comments on: Web 2.0, Destroyer of Dreams http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/ After all, it could only cost you your life, and you got that for free. Fri, 21 Nov 2008 02:34:30 +0000 http://wordpress.org/?v=2.6.2 By: Paul Kuliniewicz http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1179 Paul Kuliniewicz Sun, 22 Apr 2007 01:48:56 +0000 http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1179 Upon further consideration, the semantics of the updates sent by the client are very much HTTP POSTs and not HTTP GETs, and I'm not aware of a good way to do a POST in JavaScript without using XMLHttpRequest. I suppose I could fill the IFRAME with an HTML form that does a POST and use JavaScript to fill out the fields and trigger the submission, but that's starting to look <em>very</em> hackish. Plus, giving the server side of things some thought, a single persistent bidirectional connection with each client looks to be <em>much</em> cleaner and easier to implement than a bunch of HTTP requests flying back and forth. I'm increasingly inclined to think the applet or standalone app approach is more technologically feasible than a shiny buzzword-compliant Web 2.0 app. And the compatibility issue with a Java applet could be largely dealt with by pointing the user in the direction of where they can download the necessary plugin. I mean, that's what everyone does with Flash so they can watch Homestar Runner and YouTube, right? Upon further consideration, the semantics of the updates sent by the client are very much HTTP POSTs and not HTTP GETs, and I’m not aware of a good way to do a POST in JavaScript without using XMLHttpRequest. I suppose I could fill the IFRAME with an HTML form that does a POST and use JavaScript to fill out the fields and trigger the submission, but that’s starting to look very hackish.

Plus, giving the server side of things some thought, a single persistent bidirectional connection with each client looks to be much cleaner and easier to implement than a bunch of HTTP requests flying back and forth.

I’m increasingly inclined to think the applet or standalone app approach is more technologically feasible than a shiny buzzword-compliant Web 2.0 app. And the compatibility issue with a Java applet could be largely dealt with by pointing the user in the direction of where they can download the necessary plugin. I mean, that’s what everyone does with Flash so they can watch Homestar Runner and YouTube, right?

]]> By: Paul Kuliniewicz http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1177 Paul Kuliniewicz Sat, 21 Apr 2007 11:30:12 +0000 http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1177 I'm not up on all the web programming tricks, but that means using JavaScript to load the URL in a hidden IFRAME, instead of using XMLHttpRequest to fetch it, right? Since it's technically not the JavaScript code itself issuing the request, the browser will allow keep-alive. I think. That just might work, assuming the browser can send the new request off before the user tries to issue the next one. On the plus side, I wouldn't care what the response is, so the code doesn't have to wait for one before sending the next request. It's worth a try, I suppose. I’m not up on all the web programming tricks, but that means using JavaScript to load the URL in a hidden IFRAME, instead of using XMLHttpRequest to fetch it, right? Since it’s technically not the JavaScript code itself issuing the request, the browser will allow keep-alive. I think.

That just might work, assuming the browser can send the new request off before the user tries to issue the next one. On the plus side, I wouldn’t care what the response is, so the code doesn’t have to wait for one before sending the next request. It’s worth a try, I suppose.

]]> By: fluffy http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1176 fluffy Sat, 21 Apr 2007 04:17:47 +0000 http://www.kuliniewicz.org/blog/archives/2007/04/20/web-20-destroyer-of-dreams/#comment-1176 You could always use the classic standby of a hidden IFRAME, which would at least allow some browsers to use keepalive. You could always use the classic standby of a hidden IFRAME, which would at least allow some browsers to use keepalive.

]]>