On 07/12/11 19:12, Greg Billock wrote:
> Use cases, in my mind, are more like "play this video stream on this
> particular TV" and "grab this local content off my media server to
> upload" and "mute that amplifier." That is, they are particular
> "launches" of actions that can be bound by the UA to a potentially
> very complicated interaction going on behind the scenes. That is, even
> if we decide exactly how Web Intents will work to surface those use
> cases to web content, there will still be a great deal of work and
> thinking to do in figuring out how UAs ought to discover and interact
> with HN gear at the local network level.
>
> If the Web Intents API is being suggested as being applied more
> broadly -- that is, something that wouldn't be anchored to web content
> -- that's something I really haven't considered. I think we should
> focus on applications to the web ecosystem, and that broadening like
> this won't be fruitful. If it turns out that there are clever ways for
> the UA to take advantage of the work to provide functionality to
> non-web-content apps or whatever, that's fine, but I think our primary
> responsibility ought to be to web content developers and users.
>
> -Greg
Before we cut back the scope of web intents in that way, I think it is
worth taking a look at what value web intents offers to users and
developers. An intent can be considered as a kind of action that the app
wants to perform on behalf of the user. The set of such actions is open
and a matter for agreement between app developers and intent providers.
When it comes to selecting a particular provider, e.g. a particular TV,
this is a matter for the UA together with an means for the UA to support
3rd party extensions. Having bound the intent to a provider, there may
be further ways to establish what the particular binding can do, and how
you communicate with it. There are many ways in which this could be
realized, and I would suggest it lies beyond the scope of the core web
intents spec. One technique is a queryInterface method where the app
tries to cast the object returned by the web Intent binding to a named
interface. Another approach is to provide a rich description in some
format (e.g. XML, JSON or RDF). This can be specified separately for
given intents.
Another issue is the extent that the intent is associated with a
persistent context. A simple example is to remember the user's choice of
binding for a given intent. However, the context could be much richer,
and deal with the detailed choices a user makes when exploiting an
intent through a given binding, e.g. for controlling a sophisticated
home entertainment system. This is something that a given binding would
handle via means to persist state including user preferences. It needn't
effect the core web intents specification.
I would like to see a way for users to be able to name particular
devices/instances of services, and it may be worth exposing these names
in a way that apps can use when requesting a particular intent, e.g. the
names I use for my various TVs. This would simplify the end user
experience when different bindings are chosen in different contexts.
Actions for web content could be quite complicated too, and the same
model applies.
In summary, the services provided by a given intent binding and the
description of those services is important, but should be specified
separately from the core web intents spec, and will vary according to
the intent. We may want to consider ways for apps to pass additional
context when requesting a particular intent based upon end-user supplied
information, but this can be done in a simple way, e.g. as a string
that the UA or 3rd party extension interprets for a given intent.
p.s. Philipp Hoschka has asked me to add some info about discovery and
web intents to the DAP WG page, including a brief description of the
aims, where to look for more details (e.g. this list) and the expected
roadmap. I will look to you guys for help with that.
--
Dave Raggett<dsr@w3.org> http://www.w3.org/People/Raggett