Hi,
I''d like to implement a robust command queue for an ajaxy web app. I
was wonder if anyone would be able to feed me back any constructive
criticism that comes to mind on this.
The problem in my mind is that if an xhr request is dropped by the
network (or never makes it out of the browser''s machine etc), I want
the server to ignore further xhr commands until it turns up (if it''s
truly lost, the user sees that a box on the page is still displaying
''Syncing ...'', so knows to reload the page manually).
One approach I''ve thought of involves each xhr including a
''command
ID'' param, a simple incrementing integer. Then, server-side there is a
queue of incoming commands. If a sent xhr is dropped by the network,
the server will then detect the missing ID and will queue up all
incoming commands until the missing command turns up, or until the
user refreshes the page and the command ID is reset.
This is how it would break down:
1. user loads page, session[:cmdID] = 0
2. user initiates xhr command A, params[:cmdID] = 0
3. server receives A, sets session[:cmdID] = 1, sends response
[ all is well so far, continuing this session: ]
4. user initiates xhr command B, params[:cmdID] = 1
[ xhr is lost in the ether before it reaches the server ]
5. user initiates xhr command C, params[:cmdID] = 2
6. server recieves C, but deduces there was a missing command because
an xhr with params[:cmdID] == 1 was never received
7. server queues C and waits for B to turn up.
Meanwhile clientside javascript knows the response to B was never
received, so clearly shows this in a status bar ("Syncing …"). Any
links exiting this page are disabled until all xhr requests have been
resolved. Or, if the user can hit Refresh on their browser, so the
client view is manually synced.
Probably there are some further complexities (what happens if the
response to (3) is never received by the client? Perhaps just make
sure that any potentially conflicting actions are disabled clientside
until the response is received)
- maybe this is the starting point. What do y''all think?
[ nb I think this is really where Google Gears would shine? But I
definitely can''t rely on the userbase installing a plugin! ]
Thanks!
Darren
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Hi, more potential edge cases than actual criticism, but: - Watch out for session race conditions (likely to happen if there is overlap in the processing of the requests). - What do you do if requests are processed in a different order from the order in which they where sent (eg because the second request is routed to a mongrel that is free but the first one is routed to a mongrel that is processing a request and has to wait) ? - Watch out for users with more than one tab/browser window open onto your website Fred On Oct 1, 7:40 pm, darren <blogposts.dar...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > I''d like to implement a robust command queue for an ajaxy web app. I > was wonder if anyone would be able to feed me back any constructive > criticism that comes to mind on this. > > The problem in my mind is that if an xhr request is dropped by the > network (or never makes it out of the browser''s machine etc), I want > the server to ignore further xhr commands until it turns up (if it''s > truly lost, the user sees that a box on the page is still displaying > ''Syncing ...'', so knows to reload the page manually). > > One approach I''ve thought of involves each xhr including a ''command > ID'' param, a simple incrementing integer. Then, server-side there is a > queue of incoming commands. If a sent xhr is dropped by the network, > the server will then detect the missing ID and will queue up all > incoming commands until the missing command turns up, or until the > user refreshes the page and the command ID is reset. > > This is how it would break down: > > 1. user loads page, session[:cmdID] = 0 > > 2. user initiates xhr command A, params[:cmdID] = 0 > > 3. server receives A, sets session[:cmdID] = 1, sends response > > [ all is well so far, continuing this session: ] > > 4. user initiates xhr command B, params[:cmdID] = 1 > > [ xhr is lost in the ether before it reaches the server ] > > 5. user initiates xhr command C, params[:cmdID] = 2 > > 6. server recieves C, but deduces there was a missing command because > an xhr with params[:cmdID] == 1 was never received > > 7. server queues C and waits for B to turn up. > > Meanwhile clientside javascript knows the response to B was never > received, so clearly shows this in a status bar ("Syncing …"). Any > links exiting this page are disabled until all xhr requests have been > resolved. Or, if the user can hit Refresh on their browser, so the > client view is manually synced. > > Probably there are some further complexities (what happens if the > response to (3) is never received by the client? Perhaps just make > sure that any potentially conflicting actions are disabled clientside > until the response is received) > > - maybe this is the starting point. What do y''all think? > > [ nb I think this is really where Google Gears would shine? But I > definitely can''t rely on the userbase installing a plugin! ] > > Thanks! > Darren--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
hm, yeah .. does seem to be very hacky - worthy of some serious programming. On Oct 1, 11:56 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > more potential edge cases than actual criticism, but: > > - Watch out for session race conditions (likely to happen if there is > overlap in the processing of the requests). > > - What do you do if requests are processed in a different order from > the order in which they where sent (eg because the second request is > routed to a mongrel that is free but the first one is routed to a > mongrel that is processing a request and has to wait) ? > > - Watch out for users with more than one tab/browser window open onto > your website > > Fred > > On Oct 1, 7:40 pm, darren <blogposts.dar...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Hi, > > > I''d like to implement a robust command queue for an ajaxy web app. I > > was wonder if anyone would be able to feed me back any constructive > > criticism that comes to mind on this. > > > The problem in my mind is that if an xhr request is dropped by the > > network (or never makes it out of the browser''s machine etc), I want > > the server to ignore further xhr commands until it turns up (if it''s > > truly lost, the user sees that a box on the page is still displaying > > ''Syncing ...'', so knows to reload the page manually). > > > One approach I''ve thought of involves each xhr including a ''command > > ID'' param, a simple incrementing integer. Then, server-side there is a > > queue of incoming commands. If a sent xhr is dropped by the network, > > the server will then detect the missing ID and will queue up all > > incoming commands until the missing command turns up, or until the > > user refreshes the page and the command ID is reset. > > > This is how it would break down: > > > 1. user loads page, session[:cmdID] = 0 > > > 2. user initiates xhr command A, params[:cmdID] = 0 > > > 3. server receives A, sets session[:cmdID] = 1, sends response > > > [ all is well so far, continuing this session: ] > > > 4. user initiates xhr command B, params[:cmdID] = 1 > > > [ xhr is lost in the ether before it reaches the server ] > > > 5. user initiates xhr command C, params[:cmdID] = 2 > > > 6. server recieves C, but deduces there was a missing command because > > an xhr with params[:cmdID] == 1 was never received > > > 7. server queues C and waits for B to turn up. > > > Meanwhile clientside javascript knows the response to B was never > > received, so clearly shows this in a status bar ("Syncing …"). Any > > links exiting this page are disabled until all xhr requests have been > > resolved. Or, if the user can hit Refresh on their browser, so the > > client view is manually synced. > > > Probably there are some further complexities (what happens if the > > response to (3) is never received by the client? Perhaps just make > > sure that any potentially conflicting actions are disabled clientside > > until the response is received) > > > - maybe this is the starting point. What do y''all think? > > > [ nb I think this is really where Google Gears would shine? But I > > definitely can''t rely on the userbase installing a plugin! ] > > > Thanks! > > Darren--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---