+1 Peter Musgrave On 2011-01-31, at 10:20 PM, Erik Lagerway wrote:
Agreed.
Erik Lagerway | hookflash | m. 604.562.8647 | www.hookflash.com
On Mon, Jan 31, 2011 at 1:04 PM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
Could not agree with you more Erik on the need for SIP signaling compatibility, was just trying to avoid the “Flash” word :-) Which I believe would work not just fine, but also be the best of the breed. I hope we don’t discuss this here any more however since this list is about de jure standards.
The main issue is to avoid the Chronos effect by constraining the API standard with the 1990s limitations of SIP and XMPP. And also avoid the rat hole of discussing SIP vs. XMPP.
Henry
On 1/31/11 12:32 PM, "Erik Lagerway" <erik@hookflash.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
-Erik
On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote: +1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-)
The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu).
Thanks, Henry
On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch