View the release notes here: http://jquery14.com/day-01/jquery-14

Related posts:

1. jQuery 1.4.2 Released
2. jQuery 1.4 Alpha 1 Released
3. jQuery 1.4a2 (Alpha 2) Released

"Long polling" is the name used to describe a technique which:

• An AJAX request is made (utilizing a javascript framework such as jQuery)
• The server waits for the data requested to be available, loops, and sleeps (your server-side PHP script)
• This loop repeats after data is returned to the client and processed (usually in your AJAX request's onComplete callback function)

This essentially simulates a continuous real-time stream from the client to the server. It can be more efficient than a regular polling technique because of the reduction in HTTP requests. You're not asking over and over and over again for new data - you ask once and wait for an answer. In most cases this reduces the latency in which data becomes available to your application.

There are a variety of use cases in which this technique can be handy. At the top of the list are real-time web-based chat applications. Each client executes a long polling loop for chat and user events (sign on/sign off/new message). Meebo is perhaps the greatest example of this.

It's important to note some of the server side technical limitations of long polling. Because connections remain open for considerably longer time than a typical HTTP request/response cycle you want your web server to be able to handle a large number of simultaneous connections. Apache isn't the best candidate for this type of situation. nginx and lighttpd are two lightweight web servers built from the ground up to handle a high volume of simultaneous connections. Both support the FastCGI interface and as such can be configured to support PHP. Again, Meebo uses lighttpd.

For similar reasons - it's also a good idea to choose a different sub-domain to handle long polling traffic. Because of client side browser limitations you don't want long polling connections interfering with regular HTTP traffic delivering page and media resources for your application.

Implementation

jQuery makes implementation a breeze.

var lpOnComplete = function(response) {
	alert(response);
	// do more processing
	lpStart();
};

var lpStart = function() {
	$.post('/path/to/script', {}, lpOnComplete, 'json');
};

$(document).ready(lpStart);

Straightforward. When the document is ready the loop begins. Each iteration the returned data is processed and the loop is restarted.

On the server side - just like we discussed earlier:

$time = time();
while((time() - $time) < 30) {
	// query memcache, database, etc. for new data
	$data = $datasource->getLatest();

	// if we have new data return it
	if(!empty($data)) {
		echo json_encode($data);
		break;
	}

	usleep(25000);
}

Actually, a couple points of interest here. We don't actually loop infinitely server side. You may have noticed the logic for the while loop - if we've executed for more than 30 seconds we discontinue the loop and return nothing. This nearly eliminates the possibility of substantial memory leaks. Also, if we didn't put a cap on execution time we would need to print a "space" character and flush output buffers every iteration of the loop to keep PHP abreast to the status of this process/connection. Without output being sent PHP cannot determine if the connection was lost via connection_status() or connection_aborted(). As a result this could lead to a situation where there are an increasing number of "ghost" processes eating up server resources. Not good!

That pretty much sums it up! Not that difficult, right?

As always, questions/comments are welcome, hope this helps!

Related posts:

1. Real-time “AJAX” JavaScript Progress Bar
2. PHP Dynamic JavaScript SCRIPT Insertion for Embedding
3. PHP fast, large (megabyte), data transfer between sessions

The technique is fairly straightforward.  Here's an overview:

1. Dynamically create a hidden IFRAME
2. Post to the IFRAME
3. Backend script outputs (in real-time) individual <SCRIPT> tags to the IFRAME.
4. Each <SCRIPT> tag contains a single function call to the parent of the IFRAME ( parent.myFuncName(); )
5. Parent JavaScript function updates the status bar with newly passed parameters

A bit of background information.  The "processing" thead is initiated when a user hits the 'Screen' button.  It's an AJAX request to a PHP backend.  While executing, for each iteration, it sets status variables in memcache.  These are the variables that our "status" thread will be able to fetch.

Note: There are a variety of ways I can think of to use this same technique to achieve a real-time progress bar satisfying different situations.  For example, your "processing" thread can be your "status" thread if, for each iteration, it outputs the necessary calls we'll discuss below.  That would allow you to avoid the situation of delivering status data to a seperate thread via memcache (or some other technology).

I previously had been using an AJAX long-polling technique to achieve this.  If you're not familiar with AJAX long-polling it's essentially when you make a subsequent AJAX request on completion of the prior request to achieve a simulated, continual, "stream" from a server.  The problem in using this technique for a progress bar is two-fold:

1. Multiple, continual, repeated requests to a web server.
2. The data "stream" is pseudo real-time and is affected by variations in each request's latency.  Not very pretty.

All examples below utilize the Prototype JavaScript library.

Create the hidden IFRAME

// create status iframe
var statusFrame = new Element('iframe', { id: 'statusFrame', name: 'statusFrame' }).hide();
$$('body')[0].appendChild(statusFrame);

Post to the IFRAME

// create status form
var statusForm = new Element('form', { action: '/stocks/screenstatus', method: 'post', target: 'statusFrame' });
$$('body')[0].appendChild(statusForm);

// post to iframe
statusForm.submit();

Backend script snippet to output <SCRIPT> tags

public function screenstatus()
{
	while(1) {
		//status string
		$status = Mcache::get('status');

		// how many have been processed
		$c = Mcache::get('c');

		// how many results
		$rc = Mcache::get('rc');

		// total
		$t = Mcache::get('t');

		echo '<script type="text/javascript">parent.updateStatus("'.$status.'", '.(int)$c.', '.(int)$rc.', '.(int)$t.');</script>'."\n";
		flush();

		if(($status === false) || ($status === 'canceled') || ($status === 'complete')) {
			break;
		}

		usleep(25000);
	}
}

Parent JavaScript function to update progress bar

I chose to use a div with a background color and a dynamically adjusted width as the visual element for my progress bar. Initially the width is set to 0. In each updateStatus() call the width is adjusted to the current % of the whole (which in my case is 675px, the final desired width of the progress bar).

To overlay text I have a 2nd div styled 'position: relative;' with negative 'top' and 'bottom-margin'. This positions the textual div on top of the progress bar div.

#statusProgressBar {
width: 0px;
height: 29px;
background: #f4f4f4;
}
#statusProgress {
position: relative;
top: -29px;
left: 0;
text-align: center;
width: 675px;
padding-top: 3px;
height: 26px;
margin-bottom: -29px;
color: #00a;
font-size: 10px;
}

<div id="statusProgressBar"></div>
<div id="statusProgress"></div>

function updateStatus(status, c, rc, t)
{
	var statusHTML;
	var progressBarWidth;

	if(status == 'initializing') {
		$('statusProgressBar').setStyle({ width: '0px' });
		statusHTML = '<span id="top">Initializing...</span>';
	} else if(status == 'canceled') {
		$('statusProgressBar').setStyle({ width: '0px' });
		statusHTML = '<span id="top">Canceled... '+number_format(c / t * 100, 2)+'% Complete</span>';
	} else {
		if(t) {
			statusHTML = '<span id="top">'+rc+' result(s) ('+number_format((c ? (rc / c) : 0) * 100, 2)+'%)</span><br/><span id="bot">'+c+' of '+t+' processed ('+number_format(c / t * 100, 2)+'%)</span>';
		} else {
			statusHTML = '<span id="top">0 result(s)</span>';
		}
		progressBarWidth = Math.floor(675 * (c / t));
		$('statusProgressBar').setStyle({ width: progressBarWidth+'px' });
	}

	$('statusProgress').update(statusHTML);
}

You'll notice that the updateStatus() function calls number_format(). It's functionally equivalent to PHP's number_format(). Here is the JavaScript code below:

function number_format( number, decimals, dec_point, thousands_sep ) {
    // http://kevin.vanzonneveld.net
    // +   original by: Jonas Raoni Soares Silva (http://www.jsfromhell.com)
    // +   improved by: Kevin van Zonneveld (http://kevin.vanzonneveld.net)
    // +     bugfix by: Michael White (http://getsprink.com)
    // +     bugfix by: Benjamin Lupton
    // +     bugfix by: Allan Jensen (http://www.winternet.no)
    // +    revised by: Jonas Raoni Soares Silva (http://www.jsfromhell.com)
    // +     bugfix by: Howard Yeend
    // *     example 1: number_format(1234.5678, 2, '.', '');
    // *     returns 1: 1234.57     

    var n = number, c = isNaN(decimals = Math.abs(decimals)) ? 2 : decimals;
    var d = dec_point == undefined ? "." : dec_point;
    var t = thousands_sep == undefined ? "," : thousands_sep, s = n < 0 ? "-" : "";
    var i = parseInt(n = Math.abs(+n || 0).toFixed(c)) + "", j = (j = i.length) > 3 ? j % 3 : 0;

    return s + (j ? i.substr(0, j) + t : "") + i.substr(j).replace(/(\d{3})(?=\d)/g, "$1" + t) + (c ? d + Math.abs(n - i).toFixed(c).slice(2) : "");
}

I hope you found some of this code useful. I welcome comments and criticism!

Related posts:

1. PHP jQuery AJAX Javascript Long Polling
2. PHP Dynamic JavaScript SCRIPT Insertion for Embedding
3. JavaScript Event Handler