Re: Recovery for unavailable Action Providers

On Tue, Nov 22, 2011 at 2:14 PM, timeless <timeless@gmail.com> wrote:

> On Mon, Nov 21, 2011 at 8:38 PM, Paul Kinlan <paulkinlan@google.com>
> wrote:
> >> In the case of a "representative" dying or retiring, his office can
> >> return a Fatal error message during the Intent connection. The UA can
> >> offer to update its metadata after presenting this explanation to you.
>
> > Right, cool.  The assumption if the service has gone away webapp/site or
> > device then it should no longer be listed after the attempt to launch.
>
> I'm not sure that it should be immediately removed. In a bigger gui,
> i'd expect it to have an /!\ mark or similar. Using Printing as an
> example, if I try to print on Windows to a printer and the printer is
> offline or similar, I'll end up with a job in my print queue and there
> will be an icon badge indicating that the printer is having problems.
> I might still want to print to it later (someone could fix the
> printer, add paper, turn it on, etc.).
>
> If we assume that users can select Default Providers for Actions, then
> I think it's reasonable to temporarily unset the Provider's Default
> status if the last attempt to use it failed.
>

That sounds fair. More generally, I don't think we should specify many
details about how the UA manages the intent resolution. Leaving that up to
the UA provides the most versatility. (It could be a promising arena for
extensions...)



>
> > In your representative example, is it returned to the Individual (client
> > app) or does the User Agent allow the User to pick another Partner
> > (Representative).
>
> It is not returned to the client app. The user can pick another
> Partner (Representative), or give up.
>
> The user should have two ways to give up (but this is unrelated to the
> case of a failed Partner):
> 1. Tell the client that it worked but without sending it anywhere
> 2. Tell the client that the user couldn't find a satisfactory Partner.
>

Currently in our prototype, I'm providing several avenues for failure
notification. If the user can't find a service, or chooses to simply close
the picker without going further, that's a distinct error code from the
case where the user selects a service, but then bails out, which is
distinct from the service itself being able to call postFailure() to the
intent to indicate some kind of unrecoverable problem. Currently we're just
returning all these to the client page, but a service-side failure could
also be caught by the picker, resulting in presenting the user with another
alternative. We're not sure yet how that'll play out.

-Greg