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:02:57 +0100
Message-ID: <4ECE6AB1.5040104@telecom-paristech.fr>
To: Paul Kinlan <paulkinlan@google.com>
CC: public-web-intents@w3.org
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
>>
>>
>>
>
>


-- 
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:03:33 UTC

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