Re: Moving forward with SDP control

Hi Gili,

I have gone through the link,

I suggest a middle level API there, which I am referring as the High level
API in my explanation (This might be the confusing part between us in our
previous discussion).
I don't want lower level API directly to be exposed to the application
developer, because, it requires more API interfaces (methods).
A High level API (which was referred to be middle level API in your link)
will abstract the Lower level API and, the application can access the
required information with very fewer API calls (method invocations).
In this regard, the Helper API will be more useful.

Thanks,
Kiran.




On Mon, Jul 22, 2013 at 11:57 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Hi Kiran,
>
>     I understand what you mean now. I believe we are better off with a
> "low-level API" as discussed at
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0294.html than
> the Helper API you mentioned, for two reasons:
>
>    - Adding functionality to the low-level API should be fairly
>    easy/fast.
>     - If the API simply exposes implementation then it doesn't really add
>    code to applications based on top of it. Accessing the signaling layer
>    directly will have the same benefits/costs in that you can access features
>    immediately when they're added but your application code will constantly
>    break as the signaling layer changes over time.
>
> Gili
>
>
> On 22/07/2013 1:43 AM, Kiran Kumar wrote:
>
> Dear Gili,
>
>  The Helper API I suggested to add, is only for future use.
>
>  Once the Highlevel API is finalized, people will start working on it.
>   (I hope, the high level API will have a limited number of methods for
> example a min of 1 or 2 and
> a max of 5 which will be decided later).
>
>  Down the line, when a new parameter is added into the implementation,
> which is also required to pass over the wire as a part of signalling, The
> high level API should also change. (This new parameter can be a
> modification to the existing parameter/ or it can be a new one. If it
> is modification to the existing one, we have to support the old one also
> for backward compatibility).
>
>  The new parameters may lack its importance with a fast up-gradation of
> the same or another new dominating feature. Changing High level API more
> frequently, for the sake of one or two parameters, will incur more efforts,
> time and may even effect its stability.
>
>  To avoid such problems we can implement a Helper API, parallel to High
> level API, that contains only two methods (getParameter() and
> setParameter(),( actual names will be decided later )).
>
>  The method getParameter() is used to retrive any newly added parameter,
> which is not supported by the High level API, from the low level API (from
> the call initiator/offerer side). And the method setParameter() is used to
> supply the newly added parameter, which is not supported by the High level
> API, to the low level API (at the remote peer).
>
>  getParameter() can be invoked by passing either a string argument or an
> enum like below
>
>  string getParameter("PARAMETER_NAME");
>     or
>  string getParameter(ENUM);
>
>  Based on the argument, the Low level API will return the required
> parameter. If that argument name is supposed to be exposed by the Low level
> API or it is already supported by the High level API, it will return
> ILLEGAL_ACCESS exception other wise it will return the required value (in
> the form of string string).
>
>  setParameter() can be invoked by passing a string or enum argument along
> with the value (in the form of string).
>
>  string/error_value setParameter("PARAMETER_NAME", VALUE);
>      or
> string/error_value setParameter("PARAMETER_NAME", VALUE);
>
>  This method will check the parameter name, if it is valid to change from
> the Helper API and not supported in the High level API, then the low level
> API will process it. Otherwise it will respond with ILLEGAL_ACCESS
> exception.
>
>
>  Thanks,
> Kiran.
>
>
>
> On Mon, Jul 22, 2013 at 10:06 AM, sachin dev <dev_sachin@yahoo.com> wrote:
>
>>  +adding Kiran
>>
>>    *From:* cowwoc <cowwoc@bbs.darktech.org>
>> *To:* Kiran Kumar <g.kiranreddy4u@gmail.com>
>> *Cc:* Peter Thatcher <pthatcher@google.com>; Jesús Leganés Combarro <
>> piranna@gmail.com>; Likepeng <likepeng@huawei.com>; Cullen Jennings <
>> fluffy@iii.ca>; "public-webrtc@w3.org" <public-webrtc@w3.org>; Matthew
>> Kaufman (SKYPE) <matthew.kaufman@skype.net>
>> *Sent:* Sunday, 21 July 2013 12:08 PM
>> *Subject:* 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> 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
>>
>>
>>
>>
>>
>>
>
>