W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

Re: UPnP service implementing an intent

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Thu, 24 Nov 2011 17:48:07 +0100
Message-ID: <4ECE7547.80009@telecom-paristech.fr>
To: Dave Raggett <dsr@w3.org>
CC: Paul Kinlan <paulkinlan@google.com>, public-web-intents@w3.org
On 24/11/11 17:43 , Dave Raggett wrote:
> On 24/11/11 16:02, Jean-Claude Dufourd wrote:
>> This is exactly why I said that we may have a different definition of 
>> discovery.
>> You seem to be interested mainly in discovering services that are not 
>> yet known but are directly accessible in the environment of the 
>> current device (read: that do not need an (IP) address to be talked to):
>> - peripherals connected to the current device;
>> - optional software installed on the device...
>> The Home Network TF is only interested in discovering services 
>> elsewhere on the network, on devices unknown to the discoverer.
>> And even your version of discovery is outside the scope of Web 
>> Intents if I am not mistaken.
> I suspect that this is a misunderstanding.  The intent element is just 
> one means for registering services. The UA could also perform 
> discovery over UPnP either as part of the browser or via an extension.
JCD: Yes, but that would be outside the scope of the Web Intents 
specification even if that would be a valid use of the spec.
Best regards

> This results in a mapping from intents to services and would normally 
> occur in the background. If it would help, I could produce an addon 
> for Firefox or Chromium to demonstrate this (this would not be ready 
> until end December). When the web app requests a binding for a given 
> intent, the UA displays a dialog for the user to pick a matching 
> service. This dialog could be dynamic in the sense that the UA could 
> perform UPnP (or Zeroconf) queries for new services rather than just 
> rely on what services have been seen prior to the dialog being 
> displayed. Note that that is more important for Zeroconf than for 
> UPnP. The user confirms the selection, and the binding is passed back 
> to the app as an Intent object. The app sets the function for the 
> start of the activity, and that function has access to the service 
> metadata on the Intent object.  This metadata should be sufficient to 
> establish a communication path with the service.
> An open question is how the UA or UA extension relates intent strings 
> to the service identifiers used by UPnP services. I believe that this 
> is out of scope for the Web Intents API, but please correct me if I am 
> wrong.
>> On 24/11/11 16:01 , Paul Kinlan wrote:
>>> We don't have any addresses in the discovery process, the
>>> webintent.org/share urls are a simple string that is used to allow the
>>> UA to know the task the user want't to achieve.  It could be just a
>>> plain string "read-temperature"
>>> Our current documents describe the process of registration that can be
>>> detected by the UA, via the parsing of the intent tag, but we haven't
>>> said that they only way that a UA can know about a service is via only
>>> the intent tag.
>>> As Greg said earlier, we will be able to list the intents a service
>>> supports via the chrome extension/app mechanism - this is not done via
>>> the intent tag detection and is still conformant with the spec we had
>>> defined.

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
Received on Thursday, 24 November 2011 16:48:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC