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

Hi Miguel,

On 30 Jan 2014, at 15:26, Miguel Garcia <miguelg@google.com> wrote:

> Did the wiki got shared? Can you send a pointer to the proposal in wiki format?

Thanks for your interest and sorry for the delay. We did a round of discussion here between Anssi, Hongbo and me working on unifying the proposals and making it easy for the group to participate. The Wiki page is almost ready. I�ll be posting the link latest by tomorrow.

HTH,

Dominik


> 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 13:41:07 UTC