Re: webtv-ISSUE-24: Please show feasible implementation

On Tue, 14 Jun 2011 13:51:21 +0200, Russell Berkoff  
<r.berkoff@sisa.samsung.com> wrote:

> Hello Igarashi-san,
> Thank you for your answers.
> I will point out that UPnP (or the generic use-cases in ISSUE-16) does  
> not fundamentally differ from the approach you indicate.

I think this is exactly the point we aim to reach, i.e. a generic  
architecture that enable us to support UPnP, and more.
We don't want to do again what has already been done in other FORA, so it  
make sense to have a different PoV.

For some use cases, once you have established a communication channel, you  
may be better off exchanging "proprietary" messages between the 2 Apps,
maybe because you are just running two parts of the same application  
written by the same author and being able to control the format of the  
message will allow you more flexibility.

In other cases, especially when interacting with "real" devices rather  
then Web Applications or simply when operating in an open ecosystem,
you may want to use a more standardized protocol, like the one defined by  
UPnP.

So I feel that a (trusted) communication channel is a first block we need,  
that can be used to cover several use cases.

After that, the second question is if some of the use cases require also  
some ad-hoc DOM APIs (a part from the generic ones).
This is probably something that can be discussed more in a second phase  
(i.e. in a WG),
but to enable that is important to have a list of use cases a requirement  
that UA need to fulfil to support them.
That's why I think is important to go into details of specific services  
(like Russell did in ISSUE-17) even though at the end we may implement  
them with the same generic API.

So my conclusion is: at this level is probably good to incorporate both  
type of usecases (i.e. both ISSUE-17 and ISSUE-24),
while leaving for a later stage to identify the best technical way to  
cover both.


/g


> An application-id is similar to a serviceType in UPnP. The author of a  
> service (serviceType) defines the methods and parameters supported by  
> that service. In UPnP services are discovered dynamically although some  
> commonly used devices like media servers and renderers have include  
> pre-defined sets of services that control various aspects of device  
> control. For example UPnP groups playback control (play, stop pause) an  
> rendering controls (set brightness, set volume, etc) as separate  
> services in a media renderer device.
> Regards,
> Russell Berkoff
>
> ________________________________
>
> From: Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com]
> Sent: Tue 6/14/2011 4:32 AM
> To: Russell Berkoff; public-web-and-tv@w3.org
> Subject: RE: webtv-ISSUE-24: Please show feasible implementation
>
>
>
> Hello,
>
>
> My comments are interleaved below;
>
>
> From: public-web-and-tv-request@w3.org  
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Russell Berkoff
> Sent: Tuesday, June 14, 2011 7:17 PM
> To: public-web-and-tv@w3.org
> Subject: webtv-ISSUE-24: Please show feasible implementation
>
>
> Hello,
>
>
> I dont understand the proposed implementation for ISSUE-24.
>
>
> For a sender and receiver to communicate successfully they not only need  
> to be able to discover each other, but in addition they need to agree on  
> the syntax and  semantics of the communication.
>
>
> (Igarashi) Yes, I think so.
>
>
> The use-case mentions "application-id" but provides few additional  
> details. Is the use-case implying that all the messaging semantics are  
> derived from this application-id? I dont see this as being a very viable  
> ecosystem if each web-page declares its own application-id and  
> associated semantics that an arbitrary receiver may or may not  
> understand.
>
>
> (Igarashi) The use-case assumes that all message semantics are  
> identified by the application-id. In terms of the ecosystem, we assume  
> an ecosystem similar to that of the open web platform. Fundamentally,  
> such kind of basic framework provides a huge benefit of broader  
> ecosystem because each stakeholder utilizes the framework for its own  
> service and applications (assuming the semantics of message is  
> disclosed). In addition, if the semantics of message is open, any other  
> stakeholder may make the application which communicates another  
> application provided by another stakeholder. This is similar to the case  
> that service mash up of web APIs is popular on the web.
>
>
> Even one of the end-points delivered a JS wrapper around a socket to  
> facilitate the communications, then the methods provided by this wrapper  
> would need to be agreed to be the UA interfacing to the application.
>
>
> (Igarashi) I think we should separate the standardization of semantics  
> of message formats from the standardization of the basic framework for  
> the message exchange. This is reasonable because W3C cannot standardize  
> all of semantics of web communications, though W3C should some if  
> necessary.
>
>
> Thank you.
>
>
> -***---***---***---***---***---***---***---***---***--***---***---***-
>
> Tatsuya Igarashi?(Tatsuya.Igarashi@jp.sony.com  
> <mailto:Tatsuya.Igarashi@jp.sony.com> )
>
> NS Development Dept. Technology Development Group
>
> Sony Corporation
>
> (Voice) +81-3-5435-3252?(Fax) +81-3-5435-3274
>
>
>
> Could you clearly define some feasible implementations for this   
> use-case?
>
>
> Regards,
>
> Russell Berkoff
>
>
>


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 14 June 2011 15:23:04 UTC