W3C home > Mailing lists > Public > public-web-intents@w3.org > January 2012

Re: Mapping WebIntents to Network Service Discovery API

From: timeless <timeless@gmail.com>
Date: Mon, 9 Jan 2012 11:10:46 -0500
Message-ID: <CAACrNNePhh8UwHW9QDJ8h3w2MUhdVk-O5VnkxTOAWtJfTt75jw@mail.gmail.com>
To: WebIntents <public-web-intents@w3.org>
Clarke Stevens wrote:
> Here's a scenario that has probably already been explored that
illustrates my
> question:

So, your use of the word "client" is incredibly ambiguous, which is very
problematic. I'm going to use terminology I outlined [1] which should be
less ambiguous:

0. The User visits a Site that offers access to its archives for the
purpose of printing.
1. The User wishes to print a document.
1a. The Site has rows of "print" <button>s next to document titles.
1b. The User selects the document from the Site's list of documents.
2. The User clicks the "print" button for the corresponding document.
2a. The Site triggers the "print" Action with the document as the data.
3. The User-Agent has a list of known Partner Providers that support the
"print" Action.
3a. The User-Agent also is able to use UPnP (via the OS or whatever) to
learn about local printers which might not have been registered.
3b. The User-Agent has a way for the user to search for other services that
support the "print" Action.
3c. The User-Agent collates its list of available "print" Providers and
allows the User to select one.
4. The User selects a printer to handle the print request.
4a. Specifically to make your case interesting, the selected Partner
Provider is really a web based service as opposed to a proxied service.
5. Printing begins.
5a. The User-Agent load a web page for the Partner Provider in some sort of
browser container (tab, window, modal view, whatever).
5b. The Partner web page shows progress animation/status/ads/whatever [2].
5c. The User-Agent transports data from the Site page to the Partner
Provider page.
6. The printer runs out of paper before the document is completely finished.
7. The Partner notifies the User that the printer is out of paper by
updating its web page.
8. The User adds paper to the printer.
9. The print job is completed.

That's the short correction to your sequence. Below are some more detailed
clarifications:

> 3) A handful of printers that can handle the "print" WebIntent respond.

Intents as is don't get sent out like this.

The User-Agent may survey for a list of devices that support the "print"
intent, but they aren't specifically told that there's a "print" Action
pending.

> 6) The printer runs out of paper before the document is completely
finished.

The printer would need to send this report back to the User-Agent. If it
doesn't, then it sits in the printer's queue until someone fixes the
printer (this happens).

> 7) The client is notified that the printer is out of paper *** This is the
> step I don't understand how to do with WebIntents ***

We don't want the Site to be notified about such details.

The User-Agent may notify the User of this condition (and generally will if
the Partner updates its page to inform the User). If that happens, the
User-Agent may enable the user to select an alternate service for the
remaining pages (or the entire document).

At worst, the User at any time may ask the User-Agent to tell the Client
that the action has failed. This is independent of any real reason for an
action to have failed. The User may also ask the User-Agent to tell the
Client that the action has succeeded. This too is independent of any
underlying success state.

As an example:
A document is two pages long:
- the first contains map directions.
- the second contains advertising about which the User has no interest.

The user may decide that having printed the first page, the user considers
the print Intent "successful" and has no interest in printing the second
page, and thus this is a "success".

[1] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html
[2] http://www.cs.uml.edu/ecg/pub/uploads/HOWTOs/unspooler.png
Received on Monday, 9 January 2012 16:11:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 January 2012 16:11:15 GMT