- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Mon, 22 Jul 2013 02:27:29 -0400
- 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>
- Message-ID: <51ECD0D1.2040909@bbs.darktech.org>
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