Re: Moving forward with SDP control

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> 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
>