Re: exploration of non-web intent providers

On 20/04/12 14:29, Jean-Claude Dufourd wrote:

> Assuming both options are relevant,  requirements are:
> 
> REQ1: Device1 MUST advertize itself as Intents Registry and
> Dispatch in order to be discoverable by Device2.
> 
> REQ2: Device2 MUST have a way to request Device1 to register intents.
> 
> REQ3: Device2 MUST advertize itself as Intent Provider in order to
> be discoverable by Device1.
> 
> REQ4: Device1 MUST have an http server running somewhere to put the
> registration and service pages.

I wasn't sure whether REQ4 is needed for your option 2. In my demo,
Device2 (a smart phone) advertises itself via UPnP, and Device1 (a
notebook computer) registers Device2 as an Intent Provider. Device2 has
an HTTP server, but Device1 just has a browser and a worker that listens
for advertisements in the background and manages the intent registry.

The demo allows motion gestures on the phone to control the display of a
slide presentation on the notebook at the flick of a wrist. Scripts on
the notebook, can also make the phone vibrate and take a photo with the
phone's front facing camera, embedding into the current slide. The HTTP
server on the phone (implemented as a threaded android app) allows
Device1 to download the UPnP service description, to invoke RESTful
services, and to support long polling for motion gestures. [I didn't
have time to implement web socket support for the android app]

This assumes that there is a way to establish message ports between the
client application in Device1 and the intent provider in Device2, once
the user has selected the intent provider for this given intent request.

I experimented with chromium browser extensions as a means to implement
Web Intents along with UPnP. This is surprisingly tricky, and indicates
the need for a simply means to couple web intents to trusted browser
extensions. I am hoping to explore extending webkit to support this over
the next year.

UPnP discovery requires access to multicast sockets, which is something
that trusted browser extension scripts could have direct access to.
Zeroconf is a little more tricky as you have to deal with the binary
encoding of DNS messages. Low level access will also be needed to deal
with Intent Providers coupled via Bluetooth, USB or other means. The
good news is that none of this impacts the Web Intents spec, we just
need the message ports, and I want to see that covered in the first
public working draft.

The demo also raises the question of whether an intent must be for a
single service or can be for a named bundle of services. I don't think
we should rule out the latter!

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

Received on Friday, 20 April 2012 14:19:08 UTC