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

[Cameron Byrne <[e-mail]>]

On Oct 4, 2011 10:05 PM, "Randell Jesup" <[e-mail]> wrote:
>
> On 10/5/2011 12:30 AM, Matthew Kaufman wrote:
>>
>> On 10/4/2011 9:06 PM, Randell Jesup wrote:
>>>
>>> I think there will be a lot of small-to-medium users adding chat,
>>> building games, etc, who care little or not at all about the PSTN.
>>> Those are the ones who I worry about; they wouldn't realize there are
>>> issues with glare (totally ignoring PSTN) or that forking can be
>>> complex. They want a simple, one-stop-shopping solution for adding
>>> voice/video/data to their sites and games, etc.
>>
>>
>> Ok, so they don't know there's issues with glare or that forking is
>> hard. Does that mean that we solve forking in the browser?
>
>
>>> Does this mean we *have* to bake in some sort of signalling? No, it
>>> doesn't. It is an _argument_ for providing some type of signalling as
>>> a baseline default; or if not, then for starting a project to provide
>>> that.
>>>
>>> Note that I said "baseline". I did *not* say "can handle all the
>>> intricacies of the PSTN well".
>>
>>
>> So does "baseline" include handling the fact that "forking is hard", or
>> does baseline not address forking either?
>
>
> If you want me to answer that question: yes, I'd include support for some
sort of resolution of forking.  Enough to avoid getting into trouble, only.
>
>
>>> It could be something far simpler than
>>> SIP or XMPP, etc, or it could be a very dumbed-down version of one.
>>> These small users (as noted) need something to provide the basics, and
>>> to handle certain complexities that simply arise from normal usage
>>> patterns and features (like forking). Being able to access the PSTN at
>>> all using this would be a plus - but it would not be critical in my
mind.
>>
>>
>> This still doesn't mean that the browser needs to become a SIP phone,
>> any more than it needed a map rendering engine for Google Maps to exist
>> or an IMAP client for Gmail to exist.
>
>
> I am in *no way* saying it needs to be a SIP phone.  I'm saying "provide a
simple-to-use basic signalling method which it totally optional to use, and
which handles the basics needed of almost any signalling method (forking,
glare, etc)".  Nothing about phones, nothing about PSTN.
>
> We also don't ship browsers that consist of a canvas element and a JS
interpreter, though you *could* build all websites that way (more or less),
and some do (GMail and the like aren't far from it).  But most site authors
are glad they don't have to start with a bucket of rocks to build a castle
*as their only option*.
>

I agree with Randal here. Let's make simple things simple, which does not
preclude making advanced and novel things possible.

Cb
>
>>> And, as I mentioned, it could be external JS - but then it has be more
>>> solid to start with. For these simple uses - say chat with other users
>>> on someones special-interest website, 2 and multiplayer gaming, etc -
>>> we should try to pull together the minimum things any app/service
>>> developer would need to be prepared for. I think any service that
>>> allows someone to log in from multiple devices has to handle forking
>>> in some manner. Glare is always possible. What else? I'd like to see
>>> simple conferencing. Perhaps the minimum is simple enough that it
>>> makes more sense to develop a new, very simple signalling JS module,
>>> and use it in examples. This would limit the downside from not updating.
>>
>>
>> Or create a good *platform* for building RTC apps and let the developers
>> build things you've never imagined. I think that's a far better outcome
>> than building a SIP phone into the browser and then discovering that
>> most people don't want to just make phone calls.
>
>
> Again: I'm not suggesting "build in a SIP phone", and how does my proposal
in any way tie the hands of someone who wants to build it themselves?
>
>
>>> The advantage of basing it on something known is that the basics of
>>> all these protocols are well-understood.
>>>
>>> I'll paraphrase Harald (and many others in other contexts): make
>>> simple things simple, make complex things possible.
>>
>>
>> The latter is far more important than the former. If making simple
>> things simple makes complex things significantly harder or impossible,
>> you're not building a platform for innovation.
>
>
> Ok, but in this case I don't want to complicate the later - so you're
addressing a point I'm not making.  Please consider re-reading my posting
with that in mind.
>
>
> --
> Randell Jesup
> [e-mail]
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb