W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Peer-to-peer and stream APIs

From: Satish Sampath <satish@google.com>
Date: Fri, 25 Mar 2011 14:25:11 +0000
Message-ID: <BANLkTi=uPK95c7w30xTd64s_ZyQSN3Aw_A@mail.gmail.com>
I agree that the WHATWG draft looks clearer at first glance. Having
two different proposals of such similar nature requires everyone
interested in them to read and digest before figuring out how they
differ specifically. And there would be differences in understanding
which can cause further confusion in discussions.

It would be useful if Harald could propose specific changes to that
draft instead of a completely new proposal, so that we can discuss
about individual issues than which proposal to use. This could either
be a diff showing changes to the WHATWG proposal or individual
discussions in this list for each proposed change.


On Fri, Mar 25, 2011 at 1:31 PM, Stefan H?kansson LK
<stefan.lk.hakansson at ericsson.com> wrote:
> All,
> there are now two different sets of APIs public, one documented in the spec (<http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication>) and one sent the other day (<https://sites.google.com/a/alvestrand.com/rtc-web/w3c-activity/api-proposals>).
> A quick look at the API sets gives me the impression that they are on a top level quite similar. The model and the level of the two API sets seem to be more or less the same. The first set seem to me clearer, more thought through and better documented. The second one also lacks the possibility to send text peer-to-peer, something that can be very important for certain cases (e.g. gaming).
> I could go on discussing details, but my main message is: given that the two API sets are, on a top level, quite similar, would we not be better off selecting one of them, and use this as a basis for further discussion, testing and refinement?
> Working on two parallel tracks could waste implementation efforts, lead to non converging parallel discussions and possibly end up in a fragmented situation.
> My view is that a good way forward would be to use the API set in the spec as starting point, and propose enhancements/additions to it.
> Stefan
Received on Friday, 25 March 2011 07:25:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC