Re: [DRAFT] Web Intents Task Force Charter

Hi Rich,

On Nov 10, 2011, at 16:27 , Rich Tibbett wrote:
> Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents.

Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense.

> At this point, having studied the Web Intents proposal, we're unclear how this would work considering that:
> 
> a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA.
> >> WHAT WE ACTUALLY WANT: to enable auto-discovery and auto-registration of local device services and locally networked device services to the point that the user doesn't need to go out and register local devices and services upfront. When a user requests a particular service, they can then directly choose a device that implements the requested service rather than having to go through the indirection of searching out, navigating to and registering each intent provider first.

We don't currently have a fully solid specification based on which I can easily address your concern, but I would be surprised if whatever we came up with forbid the UA from auto-registering its own intent services and exposing them as it sees fit, without requiring the earlier step of having the user install it (in a similar way that in your discovery proposal devices needn't support CORS but can instead be automatically whitelisted).

I think that this joins Jose's comment, I've updated the description to definitely open up this possibility.

> b.) to then subsequently use a registered intent provider the concept is to open that provider, again as a web page in a seperate tab within the UA. From here we can then establish a bi-directional web messaging channel on which we can send and receive messages to communicate to and from that web page that is representing the current local service.
> >> WHAT WE ACTUALLY WANT: to communicate transparently with a locally-connected service (after user authorization has been established), without requiring that service to manifest itself as a web page in a new browser tab. We'd also like to speak the protocol (web sockets, http, etc) that the device currently supports.

I think that this is definitely an interesting UC. I don't think that the TF charter needs modifying to take it into account, and invite you to bring it up for consideration to the TF once we get running (which I'm hoping could be early next week if no one throws up a stink).

> My assumptions on Web Intents above may be incorrect. I'd appreciate some clarification if this is the case.

It's important to separate Intents as currently proposed and what we collectively want out of them. In order to move fast we probably don't want to pile up a zillion features there, but we equally certainly don't want this to turn into a rubber-stamping exercise. So bring the UCs on!

> Perhaps someone could take the time to describe exactly how a user could communicate with an existing TV device in their home from a web browser supporting web intents based on the above requirements?

We actually agreed that folks in the Discovery/Home Networking gang would do just that, to see if it flies.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 10 November 2011 16:02:49 UTC