On 8/17/2011 4:27 PM, Robert Buck wrote:
Hi,
Ian and I just chatted on the phone about the questions below. This
email captures our thoughts/discussion points. See comments below.
-Bob
On 08/17/2011 01:16 PM, Ian Springer wrote:
>>>> 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.
> I see UserSessionManager.refreshHttpSession() which periodically hits
> portal-war to keep its session alive, but it doesn't go through one of
> our GWT RPC proxies to send the request, so we probably don't have to
> worry about it.
>
> In any case, if we do find some other RPC calls that are outside the
> context of a particular view/navigation, then I guess we can add a way
> for the user to specify that the uuid stuff should be skipped when
> requesting a proxy instance from GWTServiceLookup., e.g.:
>
> boolean skipViewUuid = true;
> FooGWTServiceAsync fooService =
> GWTServiceLookup.getFooService(skipViewUuid);
OK, I like this. So when you ask
for the service you can ask to have
the calls invoked by that service instance skip the mechanism. Instead
of only a boolean perhaps an enumeration that had a couple of different
values. SKIP_TRUE, SKIP_FALSE (the default), SKIP_FAIL. The last
option could invoke the onFailure() method with a special Exception
lthat would signal that the response was tossed but still give you the
callback for app-level processing (almost like a finally).
>
>
>>>> 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...
> Does anyone have any thoughts on how we should deal with this?
In this case the user elected to change to a different page, so we could
for now just drop the notification entirely. In other cases when the
user changed pages we drop the notification, but not from the message
center (the AsyncCallback implementations handle the message center
notification). So we could simply change the code to drop the
notification in this one case, which should be rare, and I think it may
be reasonable to allow it to be dropped if it makes the UI more stable.
Ian pointed out an interesting case in ResourceSearchView:
CoreGUI.getMessageCenter().notify(
new
Message(MSG.view_inventory_resources_uninventorySuccessful(),
Severity.Info));
ResourceSearchView.this.refresh();
Here you see the .notify call but then a refresh. If the user moved away
from the page and yet we permitted the callback to be called, the
.refresh() call could cause global uncaught exceptions (perhaps NPEs).
Any case where we .notify and .refresh are candidates for UI instability
if the user changed the page.
After the conversation I am more convinced that explicit page
transitions should drop all async responses related to previous pages.
I am going to mock this up and put this onto the branch for review and
testing. But I will also investigate options on how to .notify on "old"
events w/o refreshing; but the purpose would be to cite options, not to
implement them. They could be implemented if users complain. There are
175 locations in the code base that would be modified to support this.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel