- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 20 Feb 2014 19:32:07 -0500
- To: public-webrtc@w3.org
If that's the approach you prefer, then I suggest going lower level and more generic. We will be in a much better position to build good wrapper APIs if the WebRTC API was even lower than it is now. Right now it feels like we get the worst of both worlds. Gili On 20/02/2014 3:19 PM, Tim Panton wrote: > On 20 Feb 2014, at 18:36, piranna@gmail.com wrote: > >> Promises will help here, but good APIs are not in contraposition of >> languages failures. Merge this calls maybe it's a little bit of sugar >> syntaxis, but it's not a bad thing at all... But definitelly, I don't >> agree with the sentence about "WebRTC is designed to build wrapping >> libraries". Low level is ok, but should be easy to use "as is", if you >> are forced to use a library you are learning to use that library, not >> the APIs that offer the browser. > Like xmlHttpRequest and DOM - which no one actually uses directly, > everyone uses jquery or angular or polymer or whatever. > > Like I said, the moment we decided not to do an API that > embedded a single signalling protocol ( eg SIP or xmpp or iax) > we at that moment decided it wouldn't be a 'highlevel' api > in the > > navigator.dial("e164@weshawk.co.uk",{video:true}); > > mould. > > Let me emphasise we made the correct decision, but you can't have a > simple highlevel API without baked in signalling (IMHO). But that doesn't > matter, because there are libraries, some of them quite good already. > > T. > > >
Received on Friday, 21 February 2014 00:33:00 UTC