RE: Web Intents for local network services (DAP Action-510)

Hi again,

See inline below.

Claes

-----Original Message-----
From: Giuseppe Pascale [mailto:giuseppep@opera.com] 
Sent: den 4 juni 2012 13:56
To: public-web-intents@w3.org; Nilsson, Claes1
Subject: Re: Web Intents for local network services (DAP Action-510)

On Mon, 04 Jun 2012 12:33:44 +0200, Nilsson, Claes1  
<Claes1.Nilsson@sonymobile.com> wrote:

> Hi Giuseppe,
>
Hi Claes


> The purpose of my comment on Action 511 was just to clarify that support  
> for services on legacy UPnP devices is out of scope for our current work.
>
Sure
My point (to the group) was that I was hoping we could come up with a  
solution that could handle both scenarios (even if with minor tweaking).
If this is not the preferred approach, I'm not sure at this time is  
meaningful to develop a separate solution for legacy devices. So I would  
like to see how your (and other) proposals proceed before doing any work.  
Furthermore, mapping on existing services would require a formal  
definition of some intents Verbs these could be mapped on. So I would like  
to drop Action-510 for now (or hand in to someone else that is willing to  
take it)

[claes] I agree that the ideal situation would be a solution that handles both scenarios. However, I am not sure this is possible. I am struggling to get time to write the formal specification down. Maybe it will be clearer when we have this draft specification as a discussion object.


> We see several advantages with our approach on having the Web Intents  
> service registration document and Service handler pages in the UPnP  
> device. For example, Client web pages could be written agnostic to local  
> network service discovery protocol used and the cross-domain issue for  
> control is solved as the Service page is retrieved from the UPnP device.
>

I must admit my comment was based on the V2 draft.
The approach you are taking in the latest draft takes away some of the  
concerns I had.


> I don't see why we shouldn't enable mDNS according to the same principle  
> as well.
>
As above, my concern was based on V2.
So the approach you are following now is: the common "registration" parts  
will be in a registration page, and minimal information in the discovery  
specific part.
And ideally the registration page should be equivalent (identical?) to  
what it would look like if the same service was deployed on the web.  
Correct?

[claes] Yes, that is my assumption.


If this is the case, could it make sense to reduce at a bare minimum the  
extensions for each protocol, e.g. even remove "action.webintents.org"  
 from the SSDP response so to avoid duplication (and potential conflicts)  
with the registration page? Is it really too much overhead having to check  
the registration page of devices on the Home Network that declare to  
support a "WebIntent" service, given that this will probably be done in BG  
 from the use agent and without waiting the first time intents are used?

[claes] The reason why we proposed the "action.webintents.org" SSDP header was to achieve a solution that scales better by being able to filter the SSDP responses. In a large company subnetwork there might be many Web Intents enabled devices and we considered the overhead of fetching the registration document for many devices using a battery powered mobile device. However, I am not sure how significant this is compared to the general nature of UPnP with so many messages going back and forth...So the "action.webintents.org" is not carved in stone. I understand your point of being so near the UPnP standard as possible.

/g

> Best regards
>   Claes
>
>
>
> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 1 juni 2012 18:40
> To: public-web-intents@w3.org; Nilsson, Claes1
> Subject: Re: Web Intents for local network services (DAP Action-510)
>
> I've only started now to look at the proposal but let me start by
> clarifying one thing
>
> On Tue, 15 May 2012 17:41:35 +0200, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
>
>> I have also removed the slides on Web Intents discovery of services on
>> legacy UPnP devices as I assume this is covered by
>> http://www.w3.org/2009/dap/track/actions/511.

>>
>
> To be clear: I'm not going to work on this action because so far is still
> not clear to me where we are heading.
> Furthermore, if we were to design a solution for "legacy" devices that
> will by design work with any device,
> so I'm still not sure why we want to keep the 2 separate.
>
> Most of the discovery part needs to be done inside the UA. By defining a
> new service (VS mapping well-known intents on well-known services) you  
> are
> adding burden to implementers that needs to support both.
> By further extending UPnP and mDNS you are adding yet another burden.
>
>> We are also planning to make a proposal for mDNS.
>>
> What is the advantage in slightly changing existing protocols? And if you
> are extending them anyway (i.e. you cannot reuse existing
> devices/libraries as is) why not just picking one protocol?
>
> /g
>
>> Next step is to  make a Web Intents addendum specification according to
>> http://www.w3.org/2009/dap/track/actions/510.

>>
>> Best regards
>>   Claes
>>
>> [cid:image001.gif@01CD32BB.48F373C0]
>>
>> Claes Nilsson M.Sc.E.E
>> Master Engineer, Research
>> Technology Research - Advanced Application Lab
>>
>> Sony Mobile Communications
>>  Phone:  +46 10 80 15178
>> Mobile: +46 705 56 68 78
>> Switchboard: +46 10 80 00000
>> E-Mail:
>> mailto:claes1.nilsson@sonymobile.com<mailto:claes1.nilsson@sonyericsson.com>
>> Visiting Address; Nya Vattentornet
>> SE-221 88 LUND,
>> Sweden
>> Disclaimer:
>> The information in this e-mail is confidential and may be legally
>> privileged. It is intended solely for the named recipient(s) and access
>> to this e-mail by anyone else is unauthorized. The views are those of
>> the sender and not necessarily the views of Sony Ericsson and Sony
>> Ericsson accepts no responsibility or liability whatsoever or howsoever
>> arising in connection with this e-mail.Any attachment(s) to this message
>> has been checked for viruses, but please rely on your own virus checker
>> and procedures. If you contact us by e-mail, we will store your name and
>> address to facilitate communications. If you are not the intended
>> recipient, please inform the sender by replying this transmission and
>> delete the e-mail and any copies of it without disclosing it.
>>
>>
>
>


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 4 June 2012 21:47:51 UTC