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

Re: UPnP service implementing an intent

From: Dave Raggett <dsr@w3.org>
Date: Thu, 24 Nov 2011 16:43:31 +0000
Message-ID: <4ECE7433.4070700@w3.org>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
CC: Paul Kinlan <paulkinlan@google.com>, public-web-intents@w3.org
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.  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.
Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Thursday, 24 November 2011 16:44:07 UTC

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