- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 30 Aug 2012 09:54:42 -0700
- To: public-webrtc@w3.org
It seems that a recurring theme in discussions is the cost to developers. Before I progress: ***The issue of usage complexity is irrelevant to the poll that the chairs are currently running.*** As clarified by Harald, this is about removing SDP. If anything this would *reduce* the complexity of applications that use the API. The need to write SDP parser/reassemblers would disappear. I see a lot of opinions expressed that are based purely on this misapprehension. Perhaps this is due to a confused phrasing of the question. -- What has not been properly recognized in the debate is the presence of a trade-off. Building applications that have parts outside of your control sucks. Sure, it's a natural consequence of trying to do anything more than the most trivial application. That doesn't diminish its suckitude when it comes to writing and maintaining software. For me, that's always been the attraction with open source software: when it breaks, *I* can fix it. The problem with a black box is that there is nothing I can do to fix it. All my experience with browsers suggests that it takes a long time before you can be certain that the bug has gone away for good. Bugs introduced in 2001 are only now on a small enough portion of the web that they can be effectively ignored (if you are feeling aggressive). CU-RTC-Web attempts to address that trade-off rationally. Yes, there is more work to get set up. The advantage is in how applications are empowered to deal with problems. Find a problem and there's a good chance that you can fix it. The idea that you would build an application without a third-party javascript library is just a little crazy. So, when it takes the same number of lines to include the third party library and use it, what then is the difference? Other than the fact that now you can switch libraries or fix bugs, all without bothering your browser vendor. Here's a sketch of the API that I've been building for this purpose. There's not a lot of code. It's not an full ICE agent, full interoperation with an SDP-bashing ICE agent requires a little more work. But that's unnecessary, this has all the moving parts necessary to build a usable flow. [Constructor(TransportBuilderOptions options)] interface TransportBuilder : EventTarget { readonly sequence<RealtimePort> local; readonly sequence<RemoteRealtimePort> remote; readonly RealtimeTransport? transport; void addRemote(RemoteRealtimePort rem); void start(); void stop(); void closeAll(); EventHandler? onconnect; EventHandler? oncandidate; }; dictionary TransportBuilderOptions { boolean controller = false; RemoteRealtimePort stunServer; RemoteRealtimePort turnServer; }; This requires relatively little code to build as it turns out. But it's all javascript.
Received on Thursday, 30 August 2012 16:55:11 UTC