Re: exploration of non-web intent providers

On 20/4/12 16:18 , Dave Raggett wrote:
> 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.
JCD: Where do you store the service page managing the intent provided by
the Device2, service page which in option 2 is generated by an entity on 
Device1 ?

>   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.
JCD: Right, I just concentrated on the part before the UPnP action dialog
(will be in a future email).
>
> 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.
JCD: This is the reason behind my proposal.
If nothing is standardized, then doing this UPnP link will be highly 
dependent
on the browser, whereas if the UA itself is a UPnP service, with the service
description I propose, then interface with the UA is the same as 
interface with
other services, and it will work across browsers.
Best regards
JC

>
> 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!
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144