Chat Application
-
Kevin Marois wrote:
Each Conversation would have a unique Id and a list of Participants.
I put it in a database. Each message has its own ID, the ID of its parent, and the ID of the first message in the thread. Each message also has its own set of recipients (many-to-many relationship between Message and User). The client could then display each message as it arrives, or show the entire thread in a TreeView.
Kevin Marois wrote:
API notifying clients
"Push" sucks; always has, always will. I always use polling; it allows the client/user to control frequency or even disable polling altogether. I also put in a "get messages now" feature. The server should only handle requests as they are made and not try to keep track of all the possible connections or it won't scale well. You probably also don't want to waste cycles re-trying broadcasts to clients that have lost connectivity. If no one is asking for data, don't try to send it; just wait.
Ok but with polling the client would have to make queries every 2 or 3 seconds to get close to real time
If it's not broken, fix it until it is
-
Ok but with polling the client would have to make queries every 2 or 3 seconds to get close to real time
If it's not broken, fix it until it is
Yes, only as frequently as the user wants.