- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Fri, 16 May 2014 07:26:34 +0000
- To: "mark a. foltz" <mfoltz@google.com>, Mark Watson <watsonm@netflix.com>
- CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Philipp Hoschka <ph@w3.org>, Daniel Davis <ddavis@w3.org>
- Message-ID: <3958197A5E3C084AB60E2718FE0723D47DFB7401@FEYNMAN.fokus.fraunhofer.de>
Hi Mark*,all, Sorry for late participation on the charter discussion please find my feedback inline. Regards, Louay From: mark a. foltz [mailto:mfoltz@google.com] Sent: Samstag, 10. Mai 2014 01:10 To: Mark Watson Cc: Kostiainen, Anssi; public-webscreens@w3.org; Philipp Hoschka; Daniel Davis Subject: Re: Draft of Second Screen Presentation Working Group Charter available (was: Heads-Up: Plan for Working Group on Second Screen Presentation) Hi, Thanks for the feedback all. I've authored a commit that summarizes the proposals I made earlier and may address some of MarkW's feedback as well. I expect it to generate some feedback but it is a starting point. https://github.com/webscreens/charter/pull/4 m. On Thu, May 8, 2014 at 8:46 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote: On Thu, May 8, 2014 at 12:52 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote: Hi MarkF, All, > (2) In the two-UA case, the charter hints that the software controlling the remote screen is capable of displaying arbitrary Web content. However, this is not always the case; there are a large number of devices (e.g., smart TVs, digital picture frames, set-top boxes) that can display a fixed set of "apps" or Web media types. As there are millions of these devices deployed, we feel the charter should be written so as not leave these out. I’m hearing we should clarify what is the definition of the User Agent, and make it clear that the primary device in the charter is an User Agent. Some specifications talk explicitly about an HTML User Agent to refer to web browsers explicitly. In the proposed charter we use the User Agent term, for which the established definitions reads as follows: [[ A user agent is any software that retrieves, renders and facilitates end-user interaction with web content. User agents include web browsers, media players, plug-ins, extension and web applications that help in retrieving, rendering and interacting with web content. http://www.w3.org/TR/UAAG20/#introduction ]] I share the same concern as MarkF here. I think the concern is more regarding the second screen, not the controlling device (primary device, right?). The controlling device is clearly running a User Agent in the normal sense (a browser - note that despite the definition above, UA is commonly used to refer to a browser that supports the W3C Web Platform specifications). However, as MarkF points out, the second screen may be running a set of "apps" that support a restricted set of content. Although such apps do fall under the definition of UA above (they could be called 'media players'), the use of the term User Agent to refer to them could be confusing. The requirement that the second screen support "HTML pages" is in conflict with this use-case, since such apps support specific media types or services. I haven't seen MarkF's proposed changes, but I expect what we should do is ensue that we use the more general term "web content" for what is being rendered on the second screen, rather than "HTML pages" specifically and we should explicitly include the requirement to support interaction with second screens that are restricted in the content that they can render, for example where the second screen supports a fixed set of apps for particular content types and / or services. As Mark says, there are millions of such devices deployed and (primary device) UAs that can already interact with them. ...Mark I also think extending the scope of the API to support displaying any web content will make it more powerful. From API perspective, the function for request show content on second display (requestSession(url)) is easy to adapt to any content type (url could point to a html page but also to any other web content). My concern is on the control part. In the CG API discussion, the communication part is a simple webmessaging-like channel. This is applicable when application logic is running on both end-points (control and display) but not for content. For content we need to specify control functions for each content type (e.g. for video sess = requestSession(‘example.com/video.mp4’); sess.play(); sess.pause(); etc.). I want just to clarify if this is in scope of the WG and if not, do you imagine there is another abstraction level that works for all kind of content? -- http://wiki/Main/OnlyCheckEmailTwiceADay
Received on Friday, 16 May 2014 07:27:09 UTC