Re: Proposal: Different specifications for different target audiences

This might be overly simplistic, but I would describe "control" vs 
"signaling" like this:

Control: Think "knobs and levers". You control every aspect of what 
happens by explicitly step-by-step.

Signaling: Think "reaction to stimuli". Some information gets told to 
you, system reacts based on information, result then happens.


When you can tell the system exactly the behavior you want by your own 
definition, that's control. When you can only get the system to do what 
you want based upon "negotiated information" that's signaling.


For myself, I much prefer control based APIs when possible, because what 
happens is entirely under my direction. Reactionary APIs are cumbersome 
because you have to poke the API with a stick until you get it to do 
what you want it to do.


That's one of the struggles I have with SDP O/A. Some aspects are 
"control", some things are "signaling" and very reactionary in nature. 
The lines are blurred. Even worse, you _can_ do some aspects of control 
as you can "give back" your overridden offer/answer and don't 
technically need to send anything over-the-wire (i.e. answer your own 
offer without sending to remote party). However, what you can control or 
not control isn't exactly clear. SDP O/A (as an API surface) is rather 
awkward for control.


-Robin




> cowwoc <mailto:cowwoc@bbs.darktech.org>
> 22 July, 2013 12:54 PM
>
> Tim,
>
>     Help me understand your last point. What is "signaling" to you? 
> I'm aware of two kinds of network communication: data and meta-data. 
> The first consists of audio/video data. The second consists of 
> descriptions of that data (what SDP does today).
>
>     In your proposal, what functionality is implemented in the 
> browser? Who should be encoding/decoding RTP packets? The browser or 
> the API?
>
> Thanks,
> Gili