RE: Mapping WebIntents to Network Service Discovery API

timeless wrote:
> 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.

Actually, that makes it a rather different use case than what I believe the 
UPnP-minded folks have in mind. We should consider the UPnP devices as legacy 
devices with no web capabilities whatsoever. (They use HTTP etc. but in a 
predefined manner.) I would imagine the UA, or an extension to the UA, to act 
as a bridge between the UPnP protocols and the web protocols, but I doubt if 
the UA/extension would go so far as serving up a full-blown web based service 
including the progress/animation/status/ads/whatever you pictured in 5b.

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

I would rather expect to see
5a. Control returns to the Site. (The Site really should be the main UI for 
the user.)
5b. Printer continuously sends UPnP events to the UA/its extension, with 
updates on printer state (idle/processing/stopped), reason (paper jam, out of 
paper, someone pressed the pause button), the current print queue, etc.
5c. The UPnP events are relayed to the Site.
--> This is where Clarke's question comes in - how is the relaying done?
5d. The Site updates its content to reflect the printer status, e.g. progress 
animation. If it received a job ID as part of the return data in the Intent 
invocation, it can also find the position of the print job in the print queue 
and display that to the user.

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

7. The latest UPnP event relayed to the Site would indicate that the printer 
state is "stopped" because it's out of paper. The Site notifies the user.

> 8. The User adds paper to the printer.
> 9. The print job is completed.

10. The latest UPnP event relayed to the Site would indicate that the print 
job in question has completed. The Site then notifies the user that printing 
is complete.
10a. The Site may optionally request to stop receiving events from this 
printer.

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

That is exactly what UPnP eventing is for. A UPnP printer would continuously 
send such events (reports) to anybody who cares to listen.

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

I would say that's very debatable, and may explain why these threads tend to 
diverge into two separate conversations. Coming from the UPnP world, this is 
exactly what I would want the Site to be notified of, and this is exactly why 
the question of how eventing can be done keeps coming up.

So, basically we have two different schools of thoughts here. One is that the 
Site only needs to know about the high-level actions such as share and print, 
and things like UPnP is just the low-level way of accomplishing that 
[typically one-off] task, and that the Site doesn't care whether it's UPnP or 
AppleTalk or whatever - just print the page. The other is that the Site is 
fully aware of and even designed for using UPnP to engage in a longer-term 
relationship with a UPnP device. Imagine a Site that lets you control your 
UPnP Blu-ray player. It needs feedback from the player (e.g. through events) 
to be able to show you the current playback position or enable/disable the 
play/pause button based on the current playback status.

Obviously there's no right or wrong here, just different. The main question is 
whether the Web Intent model can address both, and how/how much we would have 
to bend it to do that.

- Cathy.

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