> I expect a huge load in number of connects, but messages sent > back and forth > are light and simply. In my priliminary design, there are > basically only > three objects involved: a POST request from client, a stream > data flowing to > client and a session hash managing users/messages. No disk > file will be > involved, and when the server stops, all historical data are > gone. Well, > maybe I'll put a registation and authentication in a DB > later. I am reading > POE pm's and Randal's articles carefully -- I learned a lot > from his column > for a long time :-).
> I expect a huge load in number of connects, but messages sent > back and forth > are light and simply. In my priliminary design, there are > basically only > three objects involved: a POST request from client, a stream > data flowing to > client and a session hash managing users/messages. No disk > file will be > involved, and when the server stops, all historical data are > gone. Well, > maybe I'll put a registation and authentication in a DB > later. I am reading > POE pm's and Randal's articles carefully -- I learned a lot > from his column > for a long time :-). > This is a really interesting thread for me. I've done several online chat rooms over the past three years. The first few used refreshes of either a frame or an iframe. I got tired of two things ... Entire refreshes for no new content ( hence a waste of bandwidth to display what was already there before the refresh ), and also the jerky way it moved. I then became more confident it could be done using dynamic html. I constructed several which had no frames, but rather just one page. Every second the client would create a new javascript call to the server and recieve only the messages it needed, which were quickly added to the main screen. The bandwidth transfer for this was still very low - since in a second only a few messages could have been posted, and each message is just one function call. Every five or ten seconds ( I can't remember now ), the room would update itself for other things... new members, etc. The only drawback was occasionally a post would show from someone that didn't appear to be in the room yet. By over riding the context menu I added functionality for right clicking on the users and sending private messages, and seperate conferences. This was done by a system of tabs and divs hidden on the page. When a message came into the client in a tab that wasn't active, it would change class and highlight. The whole system didn't take long to write. It was based around perl, mod_perl and apache with postgresql providing the backend. There was no need to keep a live hash of the users and messages - history wasn't needed at all... it was just used for logging. The system got used for a short while, then we moved on. It now no longer works due to changes in our architecture, but I'm sure I could post most of the source if it's any use. I've got quite some experience of using javascript at the frontend to implement larger logic at the server side without refreshing the screen, safely, and it's used in a lot of our web applications. The reason I'm interested in this is because you mention "live-streamed" content. I feel like I'm missing a whole score of knowledge here... but how would that work. I'm away from my desk right now so I can't grab the mod_perl cookbook to take a look, but I will when I get back, don't worry :D Cheers gbjk
