2009/4/21 David Négrier <d.negrier@xxxxxxxxxxxxxxxxxxxx>: > > Here is a quick explanation of what is going on behind the scene: > > When a client loads the HTML page, a Javascript function is triggered. This > function performs an Ajax call to the server. In the case of Stuart, I > think he wrote a small fastCgi script that does trap this call (instead of > forwarding the call to PHP I Guess). > The server does not respond directly. Instead, it does not respond > directly, but it keeps the connection to the browser open. > > When someone else types something in the form, an Ajax call is performed to > the server. The fastcgi script receives this message, and sends the message > on all the open connections. > > This technique is known as "Comet". > > You can find a more detailed explanation here: > > http://meteorserver.org/interaction-modes/ The plumbing on the server-side of pnotes.org does not work like that, but that is the way the client <-> server comms works. > If you want to do the same, there are several options: > 1- You do it yourself, like Stuart did. Believe me, this is painful, > especially when you want compatibility with old browsers like IE 6, since > this > involves a lot of Javascript I beg to differ. pnotes.org uses jQuery to handle the AJAX stuff and it works quite happily on IE6. > 2- You use a Javascript framework + a light server: Orbited > (http://orbited.org) and Meteor-server (http://meteorserver.org) can help > you do such a thing. You can also google for the "Bayeux" protocol that is > a > standardised implementation of Comet. I think Dojo > (http://www.dojotoolkit.org) implements it (not sure though) > 3- You use a server side framework that will write Javascript for you. > There are several such frameworks in Java. In PHP, the only one I am aware > of is Xaja (http://www.thecodingmachine.com/ext/xaja) > 4- You decide to use Flash instead, or a framework that use Flash > underneath (http://www.apideo.com) > 5- You wait for HTML 5 that might, someday (2012?), provide a direct way to > do this ;) The reason I developed my own server-side FastCGI process is scalability. Most solutions I've seen so far are pretty heavy-weight server-side, whereas for a lot of applications it's far more than is necessary. The lightweight options out there, orbited included, usually rely on some kind of runtime (python in the case of orbited) which gives them a fairly large footprint per connected user. In the interests of scalability the server-side of pnotes.org is tiny and in using FastCGI it can hang off any web server that supports it. I wouldn't recommend Apache but both lighttpd and nginx work very well. As a consequence of that goal it's pretty limited in what it can do, but was designed in such a way that a fair number of use cases can be implemented. -Stuart > On Tue, 21 Apr 2009 10:42:54 -0400, tedd <tedd.sperling@xxxxxxxxx> wrote: >> At 3:27 PM +0100 4/21/09, Stuart wrote: >>>2009/4/21 tedd <tedd.sperling@xxxxxxxxx>: >>> > That's about it, isn't it? >>> >>>You know me better than that ;-) >>> >>>It's a live chat system with no flash in sight. No DB either, the >>>whole thing is stored in Memcached. >>> >>>When you post a message it should take no longer than a second to get >>>to all other people present. On the server-side it has a tiny >>>footprint of less than 2MB per 20 concurrent users. >>> >>>-Stuart >> >> -Stuart: >> >> Yeah, I figured that you would complicate matters considerably. ;-) >> >> And there you go again talking about stuff I'm clueless about. >> >> Okay, so we all can agree it's a form, right? >> >> And visitors can enter stuff, right? >> >> So what happens then? Please give me an outline of what happens and >> use short words. >> >> Cheers, >> >> tedd >> >> >> -- >> ------- >> http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
