W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Mon, 22 Jul 2013 02:27:29 -0400
Message-ID: <51ECD0D1.2040909@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>, sachin dev <dev_sachin@yahoo.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
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 
> <mailto:dev_sachin@yahoo.com>> wrote:
>
>     +adding Kiran
>
>     *From:* cowwoc <cowwoc@bbs.darktech.org
>     <mailto:cowwoc@bbs.darktech.org>>
>     *To:* Kiran Kumar <g.kiranreddy4u@gmail.com
>     <mailto:g.kiranreddy4u@gmail.com>>
>     *Cc:* Peter Thatcher <pthatcher@google.com
>     <mailto:pthatcher@google.com>>; Jesús Leganés Combarro
>     <piranna@gmail.com <mailto:piranna@gmail.com>>; Likepeng
>     <likepeng@huawei.com <mailto:likepeng@huawei.com>>; Cullen
>     Jennings <fluffy@iii.ca <mailto:fluffy@iii.ca>>;
>     "public-webrtc@w3.org <mailto:public-webrtc@w3.org>"
>     <public-webrtc@w3.org <mailto:public-webrtc@w3.org>>; Matthew
>     Kaufman (SKYPE) <matthew.kaufman@skype.net
>     <mailto: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
>>     <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
>>
>>
>
>
>
>
Received on Monday, 22 July 2013 06:28:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC