- From: Miguel Garcia <miguelg@google.com>
- Date: Thu, 30 Jan 2014 13:26:28 +0000
- To: "Min, Hongbo" <hongbo.min@intel.com>
- Cc: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Did the wiki got shared? Can you send a pointer to the proposal in wiki format? Miguel On Fri, Jan 24, 2014 at 9:03 AM, Min, Hongbo <hongbo.min@intel.com> wrote: > 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 Thursday, 30 January 2014 16:40:46 UTC