nextwebgen.com

The Next Generation Web Now

Two-Way Web: Can You Stream In Both Directions?

Filed under: Web 2.0 News, Front Page, Remoting, Comet — Michael Mahemoff at 6:42 pm on Thursday, July 13, 2006

Comet is mostly considered a server-to-browser thing, but how about a permanent connection in the opposite direction, from browser to server? I’ve been talking about this on my blog and received some interesting thoughts from Alex Russell.

There are two key issues:

(1) Server needs to start outputting before incoming request is finished. With a specialised server, this problem could be overcome.

(2) (More serious as we can’t control the browser) The browser would need to upload data in a continuous stream. You can do it with Flash/Java, but I can’t see how to do this with standard JS/HTML. If you use XHR, you’re going to call send() and wave goodbye to the entire request…there’s no support for sequencing it. Same if you submit a regular form, change IFrame’s source etc. Even if you could somehow delay reading of content so it’s not immediately uploaded, the browser would probably end up not sending anything at all as it would be waiting to fill up a packet.

Now I’ve seen various people mention the possibility of HTTP keep-alive, but I’ve never actually seen any concrete demos or techniques to take advantage of it from a script. So if you know of any …

Anyway, Alex Russel says it’s probably not possible, but we can get around it anyway:

So I’ve spent some time investigating this (as you might expect), and at
the end of the day there’s not much to be done aside from using Flash
and their XMLSocket interface. That’s an obvious possibility given the
high-performance Flash communication infrastructure we have in Dojo.
Doing bi-directional HTTP probably won’t happen, though, but I don’t
think that’s cause for despair. In my tests, we can get really good
(relative) performance out of distinct HTTP requests so long as the
content of the request is kept to a minimum and the server can process
the connection fast enough. HTTP keepalive exists at a level somewhat
below what’s currently exposed to browsers, so if the client and server
support it, frequent requests through stock XHR objects may verywell be
using it anyway. We’ll have to do some significant testing to determine
what conjunctions of servers/clients might do this, however.

As an interesting side note, he also pointed to some work going on at http://cometd.com to build an open Comet protocol.

PHP-Based MySQL-to-JSON Converter

Filed under: Web 2.0 News, Front Page, Remoting, Database — Michael Mahemoff at 8:23 am on Friday, July 7, 2006

A new PHP component by Adnan Siddiqi accepts a MySQL result set and converts it into a JSON message. MySQL To JSON:

This class can be used to convert data from MySQL query results into a JavaScript expression in JavaScript Object Notation.

It takes a MySQL query result handle and retrieves the query result column names and the query result data.

The class generates the definition of a JavaScript object in JSON that contains an array of a rows of query result data.

Each array element represents an object with the properties set to the query result column names. The property values are the query results for the respective row and column.

Autcompletion Issues with Yahoo, Scriptaculous Libraries

Filed under: Web 2.0 News, Front Page, Toolkit, Remoting, Yahoo!, Scriptaculous — Michael Mahemoff at 6:26 am on Thursday, June 22, 2006

Cheng Guangnan reports on a potential issue with the autocompletion/suggestion support offered by both Yahoo UI and Scriptaculous libraries. The problem involves parallel calls - there's the potential for an initial list of suggestions to be displayed after a subequent list. His screencasts show what's going on.

1. “2006” is typed.
2. A request of “2006” sent to the server.
3. User continues typing and now “200607” typed.
4. Another request of “200607” sent to the server.
5. User waiting for feedback.
6. The second request return, it show the popup.
7. The first request return, it show the popup with data returned for “2006”.

If that's the case (and we haven't verified it!), the problem could be solved by some form of Call Tracking. If the first call comes back after the second, simply discard it.