[whatwg] Peer-to-peer and stream APIs
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
Re: [whatwg] Peer-to-peer and stream APIs
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. Cheers Satish On Fri, Mar 25, 2011 at 1:31 PM, Stefan Håkansson LK stefan.lk.hakans...@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
Re: [whatwg] Peer-to-peer and stream APIs
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 stefan.lk.hakans...@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
