I''m not sure what to call this system. I''ve been trying to create something along the lines of lmgtfy''s live view[1]. It''s not working badly but I''m completely stuck on one thing. It''s turning more into a multi-user messaging system and I''m have trouble displaying message. It''s not supposed to be a fully realtime messaging app and so it uses a periodically_call_remote with an interval of 10 seconds to get new message. Right now, when a request comes in for a new message, it gets the first message with the ''seen'' flag set to false, flips the flag and displays the message. Of course this doesn''t work in a multi-user environment and once the first user has seen it, it won''t come up for any of the others. How can I rework this so that every user will see every message, but the messages won''t get repeated for a single user. Any ideas on this would be welcomed, I''ve been thinking it over all day and I can''t come up with anything. Many thanks Matt [1]http://live.lmgtfy.com
On Wed, Sep 09, 2009 at 08:57:27PM +0100, Matt Harrison wrote:> Any ideas on this would be welcomed, I''ve been thinking it over all day and > I can''t come up with anything.I think I should clarify my intent somewhat: My system should allow one or more users to submit a form which contains a string. Those strings should then (not necessarily instantly) appear on the display part of the site in the same order they were submitted. If a user opens the display portion of the site, they should only see messages that are submitted in the future, not old ones. Every user should be able to see messages from all the other users. I am thinking of doing something like: Each update changes the request parameters of the periodically_call_remote so that it passes the id of the last message displayed, then the action would return the next message by id. When the user first opens the display window, it could check the id of the last message and setup the remote_call appropriately. I haven''t tested this yet as I''m currently fiddling with something else, but I will do so in the next couple of hours. If I''m going down completely the wrong track then a push in the right direction would be great. Thanks Matt
> If a user opens the display portion of the site, they should only see > messages that are submitted in the future, not old ones.Try gem install time_machine Couldn''t resist ;)
On Wed, Sep 09, 2009 at 04:06:36PM -0700, E. Litwin wrote:> > > If a user opens the display portion of the site, they should only see > > messages that are submitted in the future, not old ones. > > Try gem install time_machine > > Couldn''t resist ;)Haha, I read that first line quickly and was about to go looking for this magical gem before I thought about it some more :D I guess really I should be looking at some messaging app sources, as that previous idea of mine failed miserably. It appears you can''t modify the periodically_call_remote behaviour without reloading the whole page, which makes sense. Thanks Matt
You might be able to put the last shown message id in a hidden field returned by the call, and then pass some JS to the :url option in periodically_call_remote. --Matt Jones On Sep 9, 7:18 pm, Matt Harrison <iwasinnamuk...-ja4MoDZtUtVl57MIdRCFDg@public.gmane.org> wrote:> On Wed, Sep 09, 2009 at 04:06:36PM -0700, E. Litwin wrote: > > > > If a user opens the display portion of the site, they should only see > > > messages that are submitted in the future, not old ones. > > > Try gem install time_machine > > > Couldn''t resist ;) > > Haha, I read that first line quickly and was about to go looking for this > magical gem before I thought about it some more :D > > I guess really I should be looking at some messaging app sources, as that > previous idea of mine failed miserably. It appears you can''t modify the > periodically_call_remote behaviour without reloading the whole page, which > makes sense. > > Thanks > > Matt
Seems to me you need to track a datetime in each client session, because your ''seen'' is relative to who''s looking. In each session, keep the datetime used, maybe in a hidden field, because your last seen is different from my last seen (I opened the view 5 seconds after you). When your periodically-call-remote evokes, pass in your datetime and server side finds the next message whose datetime is greater the datetime passed in, then pass back the message and this new datetime, rinse, repeat every 10 seconds. When I timeout and exec the periodically-call-remote 5 seconds later, it takes my datetime and does the same thing. Perhaps? -- Posted via http://www.ruby-forum.com/.
On Thu, Sep 10, 2009 at 11:27:38PM +0200, Ar Chron wrote:> > Seems to me you need to track a datetime in each client session, because > your ''seen'' is relative to who''s looking. > > In each session, keep the datetime used, maybe in a hidden field, > because your last seen is different from my last seen (I opened the view > 5 seconds after you). > > When your periodically-call-remote evokes, pass in your datetime and > server side finds the next message whose datetime is greater the > datetime passed in, then pass back the message and this new datetime, > rinse, repeat every 10 seconds. > > When I timeout and exec the periodically-call-remote 5 seconds later, it > takes my datetime and does the same thing. > > Perhaps?Thanks very much for the reply. I have tried something similar, but it failed quite badly. I tried having the rjs change the parameters for periodically_call_remote but it doesn''t seem to change anything. If I create a form with a hidden field, how can I pass that to the remote call? I''m going to try it using a session variable in a moment, the small amount of brain power I have left tells me it might work. If I can just get each request to pass either a datetime, or an id of the last message, I know I can get this to work. Thanks for the tips. Matt
Why don''t you store the messages and various flags in a database, and then just query the database? -- Posted via http://www.ruby-forum.com/.
Matt Harrison wrote:> On Thu, Sep 10, 2009 at 11:27:38PM +0200, Ar Chron wrote: >> Seems to me you need to track a datetime in each client session, because >> your ''seen'' is relative to who''s looking. >> >> In each session, keep the datetime used, maybe in a hidden field, >> because your last seen is different from my last seen (I opened the view >> 5 seconds after you). >> >> When your periodically-call-remote evokes, pass in your datetime and >> server side finds the next message whose datetime is greater the >> datetime passed in, then pass back the message and this new datetime, >> rinse, repeat every 10 seconds. >> >> When I timeout and exec the periodically-call-remote 5 seconds later, it >> takes my datetime and does the same thing. >> >> Perhaps? >> I''m going to try it using a session variable in a moment, the small> amount of brain power I have left tells me it might work.It does work :D When a user visits the display page, it gets the id of the last message and stores it in the session. Then when it polls, it gets the next message with an id greater than that stored. Then it updates the session and repeats. I''ve been testing it for an hour and it seems to be working perfectly, with the exception of one repeated message at the very start. I haven''t been able to track down what caused it but it hasn''t happened again in over 100 messages. The hard work is done thanks to the comments from you guys. Now I just have to recreate those fancy scrolling effects from live.lmgtfy.com :) Many thanks for the pointers Matt