RHQ GUI: how to deal with user clicking to navigate to view X and then clicking to navigate to view Y before X has finished loading

Robert Buck rbuck at redhat.com
Mon Aug 15 17:27:28 UTC 2011


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



On 08/15/2011 12:31 PM, Ian Springer wrote:
> This is a good idea and I think worth prototyping. We'd have to make
> sure that, when our RPC framework dropped responses, that the
> onFailure() methods would not get called on the async callback;
> otherwise an error message would still get displayed in the message bar.
>
> I understand how inbound RPC responses could be dropped if the uuids
> didn't match, but regarding the below line, how would it know to drop an
> outbound RPC request? Are you thinking that views would store the
> current request uuid in a member variable at the time they are
> constructed and then compare that with the current request uuid prior to
> each RPC invocation?
>
> On 08/15/2011 11:57 AM, Robert Buck wrote:
>> inner request A3 --->   (DROPPED OUTBOUND)
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list