On 8/17/2011 10:36 AM, Ian Springer wrote:
On 08/17/2011 09:52 AM, Jay Shaughnessy wrote:
> A couple of thoughts on this.
>
> Dropping async returns for obsolete user interactions should be a good
> way to eliminate unnecessary work, and may help avoid invalid work in
> various scenarios. But it won't eliminate invalid work in that it can
> narrow the window of vulnerability but not close it entirely. Once the
> async call returns it will still perform the processing in the
> callback. That processing may still be subject to problems if the user
> navigates away while it is in progress.
Agreed.
> What will be the mechanism to allow pass-thru for non-user-initiated
> async calls? Calls where user navigation is irrelevant, like a
> background, timer-based call to collect information or perform some sort
> of task? WIll there be a way to somehow tag the call as being
> untouchable? Or perhaps another callback method outside of onSuccess
> and onFailure, like onContextChange?
The only non-user-initiated call that is outside the context of a
particular view that we could think of is the background call that
periodically updates the alert count at the top of the page. Although
calls to periodically auto-refresh portlets or other data in the current
view are technically non-user-initiated, they are still in the context
of a particular view and so could still be assigned a tracking uuid.
I'm not
100% sure but we may have some stuff going on in the session
manager code.
> Related, although I'm not sure this is really a valid use case, it may
> be required thata use-initiated call must have its callback invoked even
> if there is a context change. For example, the async callback may need
> to itself invoke some sort of callback or listener on its completion.
That's a good point. One example I can think of is calls that update
something on the Server side (e.g. uninventorying a Resource or creating
an alert definition); ideally we'd still want to display a message
informing the user the operation had completed, even if the user had
navigated to a different page while the call was in progress. If we
short-circuit the call to onSuccess() or onFailure(), we won't be able
to display such a message...
> Jay
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel