Re: Moving forward with SDP control

Hi Kiran,

     Sorry, I don't understand.

 1. I have no doubt that the API will need to evolve over time (no one
    gets the design right the first time around). How does the Helper
    API help with this?
 2. What methods does the Helper API have? Give me some concrete code
    sniplets of how I would invoke it and what it would do under the hood.

     Please help me understand the "why" before the "how".

Thanks,
Gili

On 21/07/2013 12:13 AM, Kiran Kumar wrote:
> Dear Gili,
>
> The proposal for implementing layered design model with high level api 
> and low level api for the capabilitys object, seems to be good. It 
> will be better if both are baked into WebRTC, but of-course this can 
> be decided later.
>
> This may result in a good High level API to support JS applications 
> for now, with the existing/identified use cases and parameters.
>
> But in future, if a new invention or proposal exists, then there are 
> chances that forces to obsolete/forces to modify this High level API too.
> To avoid this problem, I would like to add/suggest a HELPER API, which 
> can also be used to interact with Low Level API, and parallel to High 
> level API.
> The functionality of this method should be as follows.
>
> 1. It should be a single method that can be invoked by passing an 
> enum/string as  argument to get the required output.
> 2. It should interact with the Low level API, to return a String 
> object for a single parameter.
> 3. It should not give access to the parameters that can be accessable 
> by the High level API and also those parameters that       are not 
> supposed be accessed.(The accesable parameters should be in agreement).
> 4. If the request is not supposed to be processed/exposed by the Low 
> level API,(determined based on the argument passed) it      should 
> return with Illegal_Access exception.
> 5. It should also return an Illegal_Access exception, if the user want 
> to set a parameter into Low level API, which is not    suposed to be 
> modified, in case of setHelper usage.
>
>
> I propose one of the two ways to implement HELPER objects.
>
> a. In this scenario, all the inputs, that are not able to pass thorugh 
> the High level API by the JS application, are passed    through the 
> constraints API. The Helper API is only used to retrive the required 
> parameters, which are not able to be done    by the High level API.
>
> b. In this scenario, constraints is used only to set the constraints. 
> setHelper() and getHelper() methods are used       respectively to set 
> and get required parameters to and/or from the low level API.
>
>
> I prefer to go with B to have a clear distinction between Constraints 
> and other parameters.(In some cases these two may concide, but it will 
> be clean if we seperate them).
>
> Thanks,
> Kiran.
>
>
> On Sat, Jul 20, 2013 at 3:49 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>     On 19/07/2013 6:10 PM, Peter Thatcher wrote:
>>         It matters because you're mixing two different API levels.
>>
>>
>>             The high-level API doesn't specify the SDP contents. This
>>         is what Web Developers use.
>>             The low-level API specifies SDP or whatever signaling
>>         format we end up using.
>>
>>             Most Web Developers will never need to see/use the
>>         low-level API and we spare them a lot of grief. Anyone who
>>         needs access to these internals can still do so, using the
>>         low-level API.
>>
>>             As a side-note, this has the added benefit of allowing
>>         you to layer different high-level APIs on top of the
>>         low-level API. If the low-level API is written in C, then you
>>         can have a JS high-level API for browsers and a Java
>>         high-level API for Android, an Objective-C high-level API for
>>         iOS, and so on.
>>
>>             If you stuff these two layers into a single API you will
>>         have to re-implement it the low-level when all you really
>>         want to do is publish a new high-level one.
>>
>>
>>     I'm completely in favor of a good lower-level API with the
>>     possibility of different higher-level APIs built on top in JS.
>>      And perhaps it even makes sense to have a higher-level baked
>>     into the browser as well.  I'm hoping that 2.0 goes in the
>>     direction of "good low-level API that higher-level APIs can build
>>     on", and we can go from there.
>>
>
>         The only thing we seem to disagree on is whether the
>     high-level API should be part of the WebRTC specification. I
>     believe that the WebRTC specification must cover *both* low-level
>     and high-level APIs otherwise you end up alienating either
>     Integrators or Web Developers. We're trying to build WebRTC, not
>     TelecomRTC :)
>
>     Gili
>
>