- From: timeless <timeless@gmail.com>
- Date: Mon, 9 Jan 2012 11:10:46 -0500
- 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 UTC