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 H. 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 
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?
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 J.
On Thu, Sep 10, 2009 at 11:27:38PM +0200, Ar Chron wrote:
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
Matt H. wrote:
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 
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
Why don’t you store the messages and various flags in a database, and
then just query the database?