- From: Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>
- Date: Fri, 13 Jun 2014 13:35:16 +0000
- To: tim panton <thp@westhawk.co.uk>, Adam Bergkvist <adam.bergkvist@ericsson.com>
- CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, Justin Uberti <juberti@google.com>, Kiran Kumar Guduru <kiran.guduru@samsung.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
>I'm sorry, but this is absurd. Why don't we implement the whole Hayes modem AT DT command >set while we are about it?
[Raju] No, implementing AT DT command set is a big NO and certainly not my preference. :-)
>We have a perfectly good dynamic programming language (Javascript) that does pattern >matches and replacements
>which is ideal for this sort of thing (should it ever be needed). I'm fundamentally >opposed to burying e164 behaviours in
>a W3C spec.
[Raju] It's not about e164 behaviors; rather it's about convenience to the developers and for easy transition to webrtc based apps. There are many areas where webrtc app can do the same without browser help because, as you said, Javascript can do anything (including audio, video codec processing!)! But, browser takes care of some of these to ease the app development so that every single developer won't have to deal with this. If it isn't that, why did webrtc add support for pause (',') symbol?!
>I'd add that the whole DTMF thing is needless anyhow - WebAudio is perfectly capable of >generating and recognising
>DTMF tones on a mediaStream.
[Raju] Right!! Why does webrtc provide support for audio/video codecs? Instead, let the developers deal with it via WebAudio filters?! Because if we leave it to app then app developers life becomes painful and there are many other things they are better off doing than doing mundane things an API can easily do!!
So, I am sorry, but the argument of "Javascript can do it, so browser should not" does not sound like a good argument to me.
BR
Raju
Received on Friday, 13 June 2014 13:35:55 UTC