RE: New Proposal: Incorporating Resume, Event-based Discovery, MessagePort

Anssi, it is okay for me to use group's wiki to put the constructor-based API proposal down. I will share it to group once it is done. Thanks.

> -----Original Message-----
> From: Kostiainen, Anssi
> Sent: Friday, January 24, 2014 4:41 PM
> To: Min, Hongbo; Rottsches, Dominik; public-webscreens@w3.org
> Subject: Re: New Proposal: Incorporating Resume, Event-based Discovery,
> MessagePort
> 
> Hi Dominik, Hongbo, All,
> 
> On 24 Jan 2014, at 08:57, Min, Hongbo <hongbo.min@intel.com> wrote:
> 
> > Inspired by the API proposal using MessagePort instead of WindowProxy,
> here comes up with an alternative API proposal from another perspective for
> how to evolve Presentation API to meet the new requirements, e.g. multiple
> display support, session resuming. In this proposal, we follow the API paradigm
> of EventSource[1], WebSocket[2] and XWLHttpRequest[3] API definitions to
> abstract each presentation session into a Presentation object, and allow
> consumer to construct arbitrary number of Presentation objects by manual,
> so-called 'Constructor-based' approach.
> >
> > Any feedback and criticism are highly appreciated, including your concerns in
> constructor-based approach, your preferred API definitions and the possibility
> to incorporate with the function based approach.
> 
> Dominik, Hongbo - thank you for investigating various options how to improve
> the API to address the new requirements. Much appreciated.
> 
> It may make it easier for the group participants to provide feedback and
> collaborate if you'd use the group's wiki to document the proposals. For
> example, the code and IDL examples are probably more readable that way.
> 
> The structure of the page could be, for example:
> 
> * Use cases
> * Requirements
> * Examples
> * IDL
> * Open issues / notes
> 
> Some of these can refer to the current spec, for example the use cases remain
> but we may want to add a new one for the flinging use case. Also, group
> participants may have additional use cases in mind too to be considered.
> 
> Once we land on consensus in the group re the shape of the API after iterating
> the design in the wiki, perhaps merging the good parts of the proposals,
> integrating proposals and changes suggested by group participants, we can
> then start to think about landing the changes to the spec proper.
> 
> But before we do that, I'd like to make sure we consider everyone's feedback
> carefully, and I think the wiki might be the right tool for the task for the first
> iteration.
> 
> Dominik, Hongbo - could you work together to create such a wiki page and
> share it with the group?
> 
> Thanks,
> 
> -Anssi

Received on Friday, 24 January 2014 09:04:36 UTC