Re: Moving forward with SDP control

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