- From: Dave Raggett <dsr@w3.org>
- Date: Fri, 20 Apr 2012 15:18:38 +0100
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- CC: public-web-intents@w3.org
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