Dominik, I agree that exposure of specific protocols via the Presentation API isn't a goal, and I don't think that's necessarily what MarkW was looking for. Rather, if we generalize the three use cases that MarkF raised (and I think there are strong valid arguments for all three), I think the high level goal is to handle a wide range of content types - HTML content, web media content, or app-specific content (e.g. a piece of content on Netflix). The role of the presentation API at it's core is to find screens that support a particular content type, and to establish (or terminate) a presentation session on a appropriate screen for that content. A view that underlies both MarkF and MarkW's view, which I share (must be a first name thing), is that messages/control in the context of an established presentation session is specific to the content being presented. Whether you load Netflix-defined HTML content on a remote HTML UA, or a pre-installed Netflix app on a DIAL device, messages within the session are entirely Netflix-defined regardless. I do agree that DIAL itself should not be in scope - indeed, per earlier comments from MarkF, the work here should not focus on any single or specific implementation technology since there are many. However, I believe it was offered by MarkW to clarify the range of presentation devices that we should support. Mark. On Tue, May 20, 2014 at 11:26 PM, Rottsches, Dominik < dominik.rottsches@intel.com> wrote: > Hi MarkW, > > >> All - do you agree that what is described above is a reasonable scope > for the API? > > > > No. User Agents should be able to support protocols such as DIAL which > > enable discovery of apps on remote devices which are capable of > > rendering particular content types or services. In such a case the UA > > can hand off rendering of URLs that do not resolve to html documents > > to such apps. > > > > The messaging protocol with such an app would be app-specific, but > > this is no different than the case of one web page communicating with > > another rendered on a remote UA. > > This might be a desirable functionality for a user agent and it is in > scope and actually already defined for the Network Service Discovery API: > > https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#discovery-and-launch-protocol-dial > > Because of this, in my opinion, we should not extend the scope of > Presentation API to expose a specific discovery protocol in order to avoid > overlap with other ongoing W3C spec efforts, as well as keeping acceptance > for Presentation API by implementors high. > > Dominik > > >
Received on Wednesday, 21 May 2014 08:43:49 UTC