W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

Recovery for unavailable Action Providers

From: timeless <timeless@gmail.com>
Date: Tue, 22 Nov 2011 17:14:47 -0500
Message-ID: <CAACrNNc5HiB04q590BGohwubGiBKDC15QVMxp_qsdw2bqJhsJw@mail.gmail.com>
To: public-web-intents@w3.org
Cc: Paul Kinlan <paulkinlan@google.com>
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.

> 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.

The wording for these two items is really poor, I know, sorry.

1 is for the case where the user decides that the Action isn't
important and doesn't need it to go somewhere and doesn't want to be
bothered by the Client trying to outthink the user. (On Windows: copy
file nul. On Unix:: cp file /dev/null)

2 is really a case where the user wants to "Cancel" and let the
application know that he's changed his mind.

> On failure we were planning on letting the user reroute the data.

I definitely want to let the user reroute data.
Received on Tuesday, 22 November 2011 22:15:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC