On 08/15/2011 01:27 PM, Robert Buck wrote:
Outbound-filtering was an optimization to avoid unnecessary busywork,
to
reduce CPU load and reduce the number of branches in the code (a
simplification actually to a single case).
Yes, somewhere have some global state, a static if you will, that is the
UUID. A mouse-click, e.g., would trigger an update to the UUID
request-id. This occurs before any RPC request is sent out. But you need
to make sure that the following holds true:
for each Ei of Ai, all Ui must be identical; that is all causally
related events MUST use the same UUID
, where E=event, A=action, U=unique-ids.
Bob
In most cases, the Ei RPC requests are sequential, where E1's
onSuccess() handler invokes E2, E2's onSuccess() handler invokes E3,
etc. In such cases, we'd be fine, because if the uuid changed during E1,
when E1 returned, it would drop its response, and E2, E3, etc. would
never get invoked.
However, I'm not sure if there are exceptions to this, where for a given
navigation, some of the requests are initiated in parallel. If there are
any such exceptions, we might need to store away the current uuid at the
time the navigation is initiated and then compare it the current uuid
prior to making the parallel outgoing RPC requests, in order to prevent
these requests from getting assigned the wrong uuid.
One example of parallel RPC requests I can think of off the top of my
head is ConfigurationEditor.onDraw(), which initiates two RPC requests
in parallel - one to retrieve the Configuration and one to retrieve the
ConfigurationDefinition. So there may certainly be other places where we
do it.