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 <[EMAIL PROTECTED]> 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
