On the subject of complexity

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