W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

RE: Proposal to remove some implementation details

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 1 Sep 2011 17:56:37 +0200
To: Anant Narayanan <anant@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A1249B08688639468D1CB181445EE79D26C0F016AD@ESESSCMS0355.eemea.ericsson.se>
On 31 augusti 2011 18:38, Anant Narayanan wrote:
> (Apologies for missing the teleconference this morning, my
> calendar messed up and I ended up being on the train 1 hour earlier
> than intended.) 
> The current working document
> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) contains
> several instances of "steps to follow" for User-Agents. This
> level of detail is probably not appropriate for our work
> (at-least at this stage), and in one instance may be out of scope for
> this working group. 
> The proposal is to remove the following text from the
> document entirely:
> - Section, Methods, "When the getUserMedia() method
> is called, the user agent must run the following steps: …"
> - Section 4, Peer to peer connections, "When the
> PeerConnection() constructor is invoked, the user agent must
> run the following steps.   This algorithm has a synchronous
> section (which is triggered as part of the event loop
> algorithm). Steps in the synchronous section are marked with ⌛…"
> - Section 5, The data stream, "When the user agent is to
> transmit a data packet to a peer using a data UDP media
> stream and with a byte string payload raw message, the user
> agent must run the following steps: …" (Arguably the entire
> data stream section is within the scope of the IETF rather
> than the W3C-WG).
> Comments welcome!
> Thanks,
> -Anant


My experience with implementing this spec (in WebKit) is that these
detailed steps are rather helpful and actually defines a lot of the
behavior. E.g.:

* defines how the options string should be parsed.
* 4. defines how the serverConfiguration should be parsed as well as how
the initial offer should be constructed. Details in this section also
affect the behavior defined in the addStream, removeStream and
processSignalingMessage sections.

Just removing these sections would defiantly make the spec harder to
implement in my opinion.

Received on Thursday, 1 September 2011 15:57:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:21 UTC