On 03/25/11 15:25, Satish Sampath wrote:
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.
I have made my specific objections to PeerConnection on this list, and
I'm awaiting some feedback from Ian and others on those before making
any more specific proposals for changes to PeerConnection.
My work was started before the revised PeerConnection API came out, and
I discussed the proposal with Ian before he published PeerConnection, so
I felt that it was fairer to publish both proposals at this time than to
bury the fact that I had been working on something else.
I'm very much in favour of ending up with one API for the management of
real-time connections between browsers. As I wrote in my first message
on the thread, I do not favor embedding this API in the HTML5 tome, but
am willing to live with that if the community decides that this is the
proper path forward.
Cheers
Satish
On Fri, Mar 25, 2011 at 1:31 PM, Stefan Håkansson LK
<[email protected]> 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
