W3C home > Mailing lists > Public > public-web-and-tv@w3.org > May 2013

RE: [apis] Content sharing use case

From: HU, BIN <bh526r@att.com>
Date: Wed, 15 May 2013 20:47:40 +0000
To: JC Verdiť <jc.verdie@mstarsemi.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <179FD336116F754C876A9347238FE29A010323F2@WABOTH9MSGUSR8L.ITServices.sbc.com>
Hi JC,

Thank you for your comment, and clarify the details of an operation path. I agree to your comment, although I think under certain circumstances, there is a possibility that the video link could be directly launched, for example, content of public, free channels, or free content (e.g. some classic movies).

I made the changes in [1] so that you comment is accommodated.

Thank you

Bin

[1] http://www.w3.org/2011/webtv/wiki/Use_Case#4._.22Use_Case_Four_.E2.80.93_Content_Sharing.22

-----Original Message-----
From: JC Verdiť [mailto:jc.verdie@mstarsemi.com] 
Sent: Wednesday, May 15, 2013 2:47 AM
To: public-web-and-tv@w3.org
Subject: [apis] Content sharing use case

Hi,

Small comment about content sharing use case [1]. It sounds to me as a 
link to content sharing more than an actual content sharing. Unless I 
missed something the mentioned content is not stored nor streamed from 
subscriber, who is only watching it streamed by the content provider. 
What he provides with the "video share button" is a link to the same 
content Then the third use case bullet:
 > Subsequently, a Facebook friend taps the shared video link, and 
launches the video on his connected device.

Would rather be in my opinion:

Subsequently, a Facebook friend taps the shared video link, and reaches 
the appropriate content provider page from which he will be able to 
launch the video on his connected device, notwithstanding the operations 
enforced by the content provider to be able to, such as credential 
checking, payment, ...


Regards,
JC



[1] 
http://www.w3.org/2011/webtv/wiki/Use_Case#4._.22Use_Case_Four_.E2.80.93_Content_Sharing.22
Received on Wednesday, 15 May 2013 20:48:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:09 UTC