Re: Moving forward with SDP control

Hi,
Adding pictorial representation for the above explanation.
Since some browser settings may show it differently, I am adding it as a
notepad attachment.
Please find the attachment for the same.

Thanks,
Kiran.


On Sun, Jul 21, 2013 at 9:43 AM, Kiran Kumar <g.kiranreddy4u@gmail.com>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> 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
>>
>
>