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

Re: UPnP service implementing an intent

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Thu, 24 Nov 2011 18:09:14 +0100
To: "Paul Kinlan" <paulkinlan@google.com>, "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>
Cc: public-web-intents@w3.org
Message-ID: <op.v5gm9o006ugkrk@giuseppep-x220>
I think we are using the term "discovery"  with different meanings, hence  
the confusion.

Web Intents allow an *application* to discover a *provider* of a certain  
service that was previously registered by the UA in some way(e.g. when the  
user navigated to a page that declared to be able to provide such service)

HN discovery protocols allow the UA to discover devices that provide  
services without users and/or applications involved.

What we should do is connect these 2 things so that intents can be used to  
expose to an application a service that the UA found on the home network.

Actually the same can be done on the web, if you happen to have a Search  
engine that can look around for <intent> tags ;)

Of course in a scenario where they do not explicitly register an intent  
provider (like going on the page that provides a service) you need to  
workout another way to preserve privacy and security. This needs to be  
handled by the UA.


On Thu, 24 Nov 2011 17:02:57 +0100, Jean-Claude Dufourd  
<jean-claude.dufourd@telecom-paristech.fr> 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.
> Best regards
> JC
> 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.
>> P
>> On Thu, Nov 24, 2011 at 1:16 PM, Jean-Claude Dufourd
>> <jean-claude.dufourd@telecom-paristech.fr>  wrote:
>>> On 23/11/11 20:01 , timeless wrote:
>>>>> All my confusion (shared by others I believe) came from trying to
>>>>> understand
>>>>> how Web Intents provided discovery, which was hopeless :)
>>>> Sorry, it does provide *a* mechanism for Discovery of /some/ services,
>>>> but the point is that it wasn't going to limit that to the only one,
>>>> and that other ways to be Discovered could be provided.
>>> JCD: We may have a different definition of discovery.
>>> I have found nothing in the current spec that allows a web app to  
>>> discover a
>>> service without having an address beforehand (whether the address is  
>>> that of
>>> the service or that of a directory).  Please correct me if you think I  
>>> am
>>> wrong.
>>> Best regards
>>> JC
>>> --
>>> 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

Giuseppe Pascale
TV & Connected Devices
Opera Software
Received on Thursday, 24 November 2011 17:09:58 UTC

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