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

[Ted Hardie <[e-mail]>]

On Tue, Sep 20, 2011 at 12:46 AM, Matthew Kaufman <[e-mail]
> wrote:

>
> By that logic we should have a built-in shopping cart to make creating web
> storefronts easier, a built-in email client to make it easier to build the
> next Gmail, etc.
>
> Except that all the interesting things that have ever happened on the web
> are because clever people used the minimal built-in stuff to make something
> much more than the sum of its parts, not because the masses used the
> pre-built parts to replicate what already exists.
>
> I don't want my web browser to have a phone inside of it. I want my web
> browser to be the thing that someone turns into the next great real-time
> communications experience... whatever that is.
>
>
I may still be jet-lagged (okay, I am still jet-lagged), but the reductio ad
absurdum of that seems to be "I don't want my web browser to have a baked in
file transfer protocol, I want it to be a platform for building the next
great file transfer protocol experience".

Having a standard signaling method for setting up media session neither
prevents the creation of other signaling methods nor does it limit what
sessions are getting created.  It does facilitate doing the things we know
we want to do in the common case--which includes  making embeddable
interactive audio/video easy to code and deploy.

Again, just my two Rappen.

Ted