pieseeelediam
New Member
In VS2010 web development vb.net, my (prototype) app provides a collaboration space, centering on a single page, which is supported by a set of home grown callback utility functions. The utilities build command and arg strings, initiate callbacks, and route callback responses. There's a corresponding callback router/resender in the page codebehind. This handles probably a couple of dozen use cases, mostly to do with either button clicks or short text entries. All works fine.I'm going to extend this utility to handle to panel updates, for a diagram and two gridviews, using control.render, which I'm already using for menus and gridview add rows.The app also has a setInterval "prompter" that sends a callback to the server every few seconds to see if the panels need to be updated based on other users inputs. That works fine.Right now, when I start what I would call a transaction callback (versus prompter callbacks, and including button clicks), I turn off the prompter setInterval, and turn it back on after receiving the callback response, so I don't get a prompter callback in the middle of my transaction callback.In reexamining all this, I'm wondering what might happen after I implement panel update callbacks. Suppose a user initiates one transaction callback (say, send a gridview add line, and retrieve the updated gridview), and while the system is waiting for that to complete, the user presses a button that initiates a second callback, before the first one completes.Right now I test and if a callback is in progress it simply does a return false on the callback initiate request. So, I might get away with that for very brief callbacks, but for the panel updates, I'm thinking that's not going to be ok (and it's probably not ok now).So it seems like two solutions might be:1) some kind of outbound message queue - but I'm having a hard time seeing what would trigger this. Although as I write this, I guess it could be triggered by the return of the previous call. That is,- put callback request in bottom of stack- take callback request from top of stack and send it to server- on receive, process the client side callback router function- at the end of the callback router function, go get the next callback request from the stack, if none found, exit2) Option 2: put a setInterval timer on each callback send request; try it three times, then punt or tell the user it failed.Clearly, having written this all out, option 1 seems much better, and apparently do-able. So, I may have solved my problem here, however, I would appreciate any comments about this in terms whether this is a standard kind of approach, potential weaknesses, etc, and any pointers to code examples that might help in implementing it.Thanks!