Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Randell Jesup <[e-mail]>]

On 9/19/2011 6:23 AM, Hadriel Kaplan wrote:
> On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote:
>
>> The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues).
>
> And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation?

Not compared to the complexity if it's all "roll-your-own".  No one suggested that
people be locked into a signalling protocol, and JS libraries are an option.  We do
have a lot of experience with pseudo-standard APIs implemented in JS, such as jquery
and many others, and these aren't unrealistic concerns.

I lean towards a proposal I made a week or two ago; to allow full access (which allows
user-written JS signalling libraries) but provide minimal SIP+O/A as an option within
the browser.  This could be a JS library, but the primary users of this would be the
"little guys" who just want simple setup of media streams, and they're most likely to
never update, while browsers are updated frequently.

> And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside.  What's worse, it won't be controllable by the JS developer.  At least with a JS library they're all using the same source code, and the JS developer knows what it was/did if it was an older version.

That's entirely available to the application; they can use their own if they wish.
And while I suggest a simple SIP set be included, if we were certain a "standard" JS
lib were freely available and solid enough, that would make the argument stronger for
a JS lib.

> With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no?

Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will be
cached to disk even if coming from https.  Note that secure (https) content by default
isn't cached unless cache-control options are set.

I would strongly warn against fetching JS libs for a service like this over http, and as
part of the security review here we may well go further than that.


-- 
Randell Jesup
[e-mail]