Re: Application architecture question

Timea,

If you've got the case of waiting on a multiplicity of RPC's to complete before continuing, something like Jen's suggestion is best. I've implemented it before with a multibit latches.

However you get into the issue of syncing. For example, let's say you have N RPC calls for a given event. If someone triggers this event twice quickly (say event A and B) that fires off 2*N RPC calls. You've no guarantee that all of A's RPC's will return before all of B's RPC's. What if B completed first? Should A update the UI too or is it no longer relevant? Essentially all of the thread locking goodness you normally avoid with JS creeps in. That is why when I've run into this pattern, I usually try to find a way to do the grouping server side rather than UI side if possible.

If you must, make sure you:

• Block all UI interaction until the event's RPC's return
• Unblock the UI on error for any RPC
• Have a way to cancel all inflight RPC's if you need to cancel the update from the UI
• Make sure you reset you latches on error/success

Sincerely,

Joseph

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.