Commits

Fred T-H  committed 61d9e0a

Details about the new web implementation.

  • Participants
  • Parent commits a91a987

Comments (0)

Files changed (1)

 * Session timeouts
 * Distribution on multiple nodes
 * Basic web-server implementation
-* Ugly javascript long-polling client (bug-ridden)
+* Javascript JSONP client
 * Basic history logs from previous conversations
 * General test suite
 
 The global module was used instead of solutions like mnesia for reasons such as automatic monitoring of registered processes, the possibility to define procedures in case of netsplits when the network comes back up, a local lookup for names, etc. This system allows to have instant distribution over many nodes.
 
 ==== Web Server and javascript implementation ====
-The current implementation is broken, to put it simply. The mochiweb server is botched-up copy/pasting and the javascript client implementation is subject to stack overflows with listen requests and doesn't break up listen calls when submitting new messages, making it easy to hit a browser's limit. Moreover, the current listen implementation will not call the server back once an error has occurred.
+The current implementation works with a basic mochiweb server implementation. It supports three basic operations: listen, message and history and responds to JSONP requests only. 
 
-It is strongly suggested that the whole browser + javascript client part should be thrown into a garbage can to never be considered again. I really need to replace it with something better.
+The javascript client has been rewritten to rely purely on jQuery and uses JSONP to avoid stack overflows and to bypass the browser limit in connections to a single domain. It also lets the implementation circumvent the same origin policy. Visually speaking, the client now supports one separate conversation block for each person someone might be talking to. Such a block is automatically added on the reception of a message or when there were entries in the recent user history with that person. Here's what it looks like:
+
+{{http://i.imgur.com/laHoi.png|Chut's UI}}
+
+This is of course meant to be re-skinned in CSS by any site to fit in with its design. All that's provided here is basic style.
+
+JSONP has the downside of appearing as if the page wasn't done loading in many browsers. The two ways there are to go around this issue are to either use iframes or use fake subdomains that increment in every client (facebook does it this way). basic JSONP was chosen for now given there are many issues to solve before that one. The facebook approach is something Chut is unlikely to implement because of the comparatively complex setup requirements.
+
+More testing needs to be done with different browser (IE6 and IE7 still need to be tested). So far the client seems to work fine with FF3.0.x, FF3.5+, Opera 10.x, Chrome, Safari 4.0.x and IE8.
 
 == What's left to be done ==
-* A better web implementation for long-polling
 * Adding logging to messages sent and received
 * Notifying the user when someone he's talking to disconnects
 * Specifying functions to deal with netsplits and user registration
 * Add more unit tests
 * Benchmark the performances
 * Making the conversation history more flexible
+* Adding wiki entries about how to build Chut
 * And much more!
 
 === How it's gonna be done ===
 
-The next most important points to extend are the web implementation and conversation history.
-
-The web implementation will likely require to start the //web_server.erl// module from scratch and to restart the javascript part from scratch too. I don't really know how I'm going to proceed for the whole thing yet, so we'll see.
-
-As for the logging system, a simple event handler listening to every message sent and logging them on disk somewhere (or in a database) is trivial to add.
+For the logging system, a simple event handler listening to every message sent and logging them on disk somewhere (or in a database) is trivial to add. That's all that needs to be done, given we have a database table already open.
 
 To notify a user someone he's talking to has disconnected, two options are possible. The first one is to add a lookup on each message sent (from the dispatch handler), which would then report that event to all connected clients. The second option is that when a discussion starts between two users, the FSM starts monitoring the other user. Whenever the FSM receives a message mentioning the death of a monitored user, the clients are made aware of it. This last option would require the potential addition of new functions to usr.erl, but would reduce the amount of lookups made within the global module and would let the status of the other user be known in real time rather than the sending of a message.