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