Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>there are (roughly) 3 options for creating a chat application:</p> <h2>sockets</h2> <blockquote> <p>use flash/java and sockets for the frontend and a socket-capable programming language for the backend. for the backend, i'd recommend java or python, because they are multithreading and NIO-capable. it's possible to do it with PHP (but php can't really do efficient multithreading and is generally not really suited for this). this is an option if you need high performance, and probably not what you're looking for.</p> </blockquote> <h2>use ajax and pull</h2> <blockquote> <p>in this case all clients are constantly (for example ever 2 seconds) polling if something new has happened. it feels strange because you only get responses at those intervals. additionally, it puts quite a strain on your server and bandwidth. you know an application uses this technique because the browser constantly refreshes. this is a suboptimal solution.</p> </blockquote> <h2>use ajax and push</h2> <blockquote> <p>this works with multipart-responses and has long running (php-) scripts in the backend. not the best solution, but most of the time it's better than pulling and it works and is used in several well known chat apps. this technique is sometimes called <a href="http://en.wikipedia.org/wiki/Comet_(programming)" rel="noreferrer">COMET</a>.</p> </blockquote> <p>my advise: if you need a chat app for production use, install an existing one. programming chat applications is not <em>that</em> easy.</p> <p>if you just want to learn it, start with a simple ajax/pull app, then try to program one using ajax and push.</p> <p>and yes, most probably you'll need a database, tough i successfully implemented a very simple ajax/pull solution that works with text files for fun (but i certainly wouldn't use it in production!). </p> <p>it is (to my knowledge, but i'm pretty sure) not possible to create a chat app without a server-side backend (with just frontend javascript alone)!</p> <h2>UPDATE</h2> <p>if you want to know how the data pushing is done, look at the source here: <a href="http://wehrlos.strain.at/httpreq/client.html" rel="noreferrer">http://wehrlos.strain.at/httpreq/client.html</a>. async multipart is what you want :)</p> <pre><code>function asSendSyncMulti() { var httpReq = new XMLHttpRequest(); showMessage( 'Sending Sync Multipart ' + (++this.reqCount) ); // Sync - wait until data arrives httpReq.multipart = true; httpReq.open( 'GET', 'server.php?multipart=true&amp;c=' + (this.reqCount), false ); httpReq.onload = showReq; httpReq.send( null ); } function showReq( event ) { if ( event.target.readyState == 4 ) { showMessage( 'Data arrives: ' + event.target.responseText ); } else { alert( 'an error occured: ' + event.target.readyState ); } } </code></pre> <p>showReq is called <em>every time</em> data arrives, not just once like in regular ajax-requests (i'm not using jquery or prototype here, so the code's a bit obese - this is really old :)).</p> <p>here's the server side part:</p> <pre><code>&lt;?php $c = $_GET[ 'c' ]; header('Content-type: multipart/x-mixed-replace;boundary="rn9012"'); sleep( 1 ); print "--rn9012\n"; print "Content-type: application/xml\n\n"; print "\n"; print "Multipart: First Part of Request " . $c . "\n"; print "--rn9012\n"; flush(); sleep( 3 ); print "Content-type: application/xml\n\n"; print "\n"; print "Multipart: Second Part of Request " . $c . "\n"; print "--rn9012--\n"; ?&gt; </code></pre> <h2>update2</h2> <p>regarding the database: if you've got a nothing-shared architecture like mod_php/cgi in the backend, you <em>definitley</em> need <em>some</em> kind of external storage like databases or textfiles. but: you could rely on memory by writing your own http server (possible with php, but i'd not recommend it for serious work). that's not really complicated, but probably a bit out of the scope of your question ^^</p> <h2>update3</h2> <p>i made a mistake! got everything mixed up, because it's been a long time i actually did something like that. here are the corrections:</p> <ol> <li><p>multipart responses only work with mozilla browsers and therefore are of limited use. COMET doesn't mean multipart-response.</p></li> <li><p>COMET means: traditional singlepart response, but held (with an infinite loop and sleep) until there is data available. so the browser has 1 request/response for every action (in the worst case), not one request every x seconds, even if nothing response-worthy happens.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload