Re: Web Intents - a short introduction

First of all, many thanks for a nice and clear introduction.

timeless wrote:
> Web Intents is designed to address the problem of a Site wanting to do
> a certain Action with a Partner known to the User but not the Site.
> The User doesn't really want the Site to know which Partner the User
> has selected, nor does the User really want the Partner to know which
> Site caused the User to contact the Partner.

The general principle of keeping the partner and the site at arms length 
is clear.

> An intent could also be something like "get-temperature"

In an application showing the temperature at many locations, presumably 
there is a way for the user to select multiple sensors, and for the 
application to access appropriate metadata for each sensor? In this 
example, the partner (the temperature sensor) wants to provide metadata 
to the site (e.g. its location), and it may be necessary for the user to 
give his/her consent. This points to the need to inform users prior to 
them making a decision as to which partners to use for this particular 
application.

User's may want this application to remember these choices for next time 
the application runs. This imposes requirements on the web run-time to 
record them in a way that can be applied independently of the IP address 
for the sensor, as that may change.  For a partner providing a service 
over a USB or Bluetooth connection, there may not be an IP address.

One idea is to provide a means for users to assign persistent names to 
partners. This works nicely for Apple's Bonjour, which ensures that each 
service has a unique name, that is initialised with a stem provided by 
the device vendor, see:

_http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NetServices/NetServices.pdf_

The responsibility for managing the names for partners (i.e. services) 
would fall upon the web run-time, but could be delegated as appropriate.

Another scenario is where an application presents a display of the 
presence of a dynamically changing population of service providers. An 
example could be an app on my smart phone showing the location of my 
friends at the Glastonbury festival where over a hundred thousand people 
are spread over a large area with many stages in a festival running over 
several days. In this case the intent identifies my friends, some of 
whom arrive a day late or leave a day early. This particular case could 
probably be addressed by mapping the intent to a service that itself 
tracks festival goers, and provides notifications when people arrive or 
leave. A more general question is how does Web Intents relate to 
notifications for when services become available or unavailable?  I 
suspect that we should deal with that separately, but that we will want 
to reuse the intent names.

What is the scope of the Web Intents specification?  It clearly has to 
address the interface exposed to web applications seeking to use 
services.  It could cover some standard intents e.g. printing, and 
services exposed by other websites.  Perhaps we can address service 
registration and discovery more generally as a set of additional 
specifications, e.g. for home networking, and services provided over 
interconnect technologies such as USB, Bluetooth, NFC and Zigbee?  
Service specific specifications would cover the interfaces and/or 
protocols for given services.

---
   Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett