hm,
yeah .. does seem to be very hacky - worthy of some serious
programming.
On Oct 1, 11:56 am, Frederick Cheung <[EMAIL PROTECTED]>
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 <[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
-~----------~----~----~----~------~----~------~--~---
