Commits

Fred T-H  committed a91a987

Changed info to reflect the new conversation history handler

  • Participants
  • Parent commits 54d6849

Comments (0)

Files changed (1)

 * Distribution on multiple nodes
 * Basic web-server implementation
 * Ugly javascript long-polling client (bug-ridden)
+* Basic history logs from previous conversations
 * General test suite
 
 === How it works ===
 * //usr_dispatch_handler//: Takes messages you send and routes them to another user. There is only one of these per user.
 * //usr_listen_handler//: Takes any kind of message received and transmits it to the client. The format of the message is altered to be {UserId, {received, From, Message}} or {UserId, {sent, To, Message}} so a given process can hold more than one client connection. There is one handler of this kind per client and each of them is added with gen_event:add_sup_handler/3, which guarantees that if the client dies, the handler also dies (the opposite is also true, except for a normal exit).
 
-These two handlers are enough to do all the message routing. Additional handlers could be added to do logging, message history, presence updates, etc.
+Another handler, namely //usr_history_handler//, exists with the sole purpose of accumulating the messages sent through a user. When the notification {From, history} (where //From// is a PID) is sent, this handler will send back a list of recent messages routed through the user.
+
+These three handlers are enough to do all the message routing and history keeping. Additional handlers could be added to do logging, presence updates, etc.
 
 
 ==== gen_fsm ====
 
 == What's left to be done ==
 * A better web implementation for long-polling
-* Enabling conversation history for the last few messages 
 * 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
 * Turn Chut into an OTP application
 * Add more unit tests
 * Benchmark the performances
+* Making the conversation history more flexible
 * And much more!
 
 === How it's gonna be done ===
 
 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 conversation history, it should be trivial to add a new event handler that will keep received and sent messages in its local state. A new message could be added with the form {From, {history, LastId}} where LastId might just be {now(), make_ref()} and would refer to the last message read. The event handler receiving this message can then reply to 'From' by sending the history needed.
-
-A similar concept can be applied for the logger. A simple event handler listening to every message sent and logging them on disk somewhere (or in a database) is also trivial to add.
+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.
 
 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.
 
 Turning Chut into an OTP application might be a little complex in terms of refactoring. The current plan is to add a top-level supervisor per node where all users will be registered. The addition and removal of users to a system will thus need to be routed through that supervisor with supervisor:start_child/2 and supervisor:terminate_child/2 (followed by supervisor:delete_child/2). This represents a little gain in complexity opposed to a good gain in simplicity when it comes to deploying and managing Chut. The web server implementation will be separate from this application. The web server will likely need to be turned to its own OTP application with a dependency on Chut, if they're to run on the same nodes.
 
-More unit tests should be one of the top priority also. So far, only a general common test suite exists, testing the general behavior of the chat users and client modules. A finer grained testing approach could help optimize some potential bottlenecks and increase confidence in the code. Load and performance testing is also needed, in order to know what load the prototype can support and if using global the way it is used might become a bottleneck when under heavy load.
+More unit tests should be one of the top priority also. So far, only a general common test suite exists, testing the general behavior of the chat users and client modules. A finer grained testing approach could help optimize some potential bottlenecks and increase confidence in the code. Load and performance testing is also needed, in order to know what load the prototype can support and if using global the way it is used might become a bottleneck when under heavy load.
+
+As for the conversation history, it should be trivial to make it better (only keeping //x// messages in memory) to something more flexible. The history message could be changed to take the form {From, {history, LastId}} where LastId might just be {now(), make_ref()} and would refer to the last message read. Otherwise,  having a conversation history that could be dispatched depending on the receiving party would also be useful. However, given what's left to do in other areas, these ameliorations will be delayed a bit.