- From: Kiran Kumar <g.kiranreddy4u@gmail.com>
- Date: Tue, 23 Jul 2013 10:13:36 +0530
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Eric Rescorla <ekr@rtfm.com>, public-webrtc <public-webrtc@w3.org>, tim panton <thp@westhawk.co.uk>, Roman Shpount <roman@telurix.com>, "piranna@gmail.com" <piranna@gmail.com>
- Message-ID: <CAGW1TF5jF9bwu5ZjbyCvuvU5An6Htxj33JZQYSfJMyprVNUZ0A@mail.gmail.com>
Hi Gili, There is a small mis-understanding here. The middle level layer what ever I am suggesting, does not include any sort of get/set methods. Its a pure abstraction to the Low level API. The get/set methods I am proposing are only some helper functionality s, parallel to middle layer, that can be useful to add extra parameters, (with out disturbing the middle level API for backward compatibility) between two releases of WebRTC. Its just for temporary use, and the accessibility for this methods will be completely under the control of browser. (This get/set methods are not shown in the above diagram. It adds an extra box parallel to middle layer). Thanks, Kiran. On Mon, Jul 22, 2013 at 9:08 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > Kiran, > > I think adding this "middle layer" is a bad idea. An API consisting of > two methods (get/set key-value pairs) is not an API. It doesn't provide any > abstraction, information hiding or any of the other useful things APIs do. > It's virtually the same as what we have today with SDP. So I'm -1 on this > proposal, sorry. > > Gili > > > On 22/07/2013 4:36 AM, Kiran Kumar wrote: > > In addition to the above (specified in my previous mail), the middle level > API removes the tight coupling between Low level API and High level API. > In most of the cases WebRTC can work with no dependency from the > Application layer API. > WebRTC and Developer groups should just follow each other with a common > agreement, but the dependency should be reduced as much as possible. > The Java script application lawyer should be able to access only the > middle level API (which is represented as high level API in > http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0434.html) > > > > ------------------------------------------------------------------------------ > | > | > | JS APP (SIP/XMPP/ ... Signalling) | > | > | > > ------------------------------------------------------------------------------ > ^ > | > V > > ----------------------------------------------------------------------------------------------------- > | webrtc-platform/webkit > | > | > | > | > ---------------------------------------------------------------------------------- > | > | | > | | > | | Middle level API > | | > | | > | | > | > ---------------------------------------------------------------------------------- > | > | ^ > | > | | > | > | v > | > | > ---------------------------------------------------------------------------------- > | > | | > | | > | | Low level API > | | > | | > | | > | > ------------------------------------------------------------------------------------ > | > | > | > > --------------------------------------------------------------------------------------------------------- > > > > On Mon, Jul 22, 2013 at 12:49 PM, Kiran Kumar <g.kiranreddy4u@gmail.com>wrote: > >> Hi, >> IMHO Signalling (SIP, XMPP etc) should not be a part of browser. Browser >> implementation should be independent of the signalling as it is now. >> I agree that Low level API should abstract implementation details (of >> media, sockets, transport etc). >> I would like to have one more layer on top of this, to abstract even >> this, Low level API (few members are calling it as Middle level API). >> Both of these should be in control of Browser. >> >> >> Thanks, >> Kiran. >> >> >> On Mon, Jul 22, 2013 at 8:47 AM, piranna@gmail.com <piranna@gmail.com>wrote: >> >>> Maybe not directly plain SIP but an API that abstract it so maybe in the >>> future it's being used XMPP instead (I've been working in this >>> server-agnostic issue), but definitely "SIP in the browser" (or equivalent) >>> as WebRTC spec defined signaling channel is not a bad idea... +1 >>> El 22/07/2013 05:03, "Eric Rescorla" <ekr@rtfm.com> escribió: >>> >>> On Sun, Jul 21, 2013 at 7:41 PM, cowwoc <cowwoc@bbs.darktech.org>wrote: >>>> >>>>> On 21/07/2013 9:31 PM, Eric Rescorla wrote: >>>>> >>>>> What does "SIP in the browser" mean? I assume you don't mean >>>>> literally. >>>>> >>>>> No, I mean it literally. Minimally, the JS would have no meaningful >>>>> visibility into the signaling messages (i.e., the JS would just request >>>>> that the messages be transmitted) and maximally you would >>>>> actually send messages via SIP. >>>>> >>>>> >>>>> In my original proposal, the implementation of the low-level API >>>>> is all about parsing the signaling layer. The high-level API never sees the >>>>> signaling layer and it definitely is not "SIP in the browser". I disagree >>>>> with exposing SIP anywhere, even in the lower-level API. If you want to use >>>>> SIP in the signaling implementation that's fine, but the object API should >>>>> not expose these implementation details to the outside world. >>>>> >>>> >>>> Yes, and as I said, the WG rejected this approach, just as it >>>> rejected the >>>> low-level API approach. My point was merely that "high-level", >>>> "mid-level", >>>> and "low-level" are terms that already have meaning in this WG. It would >>>> be useful if you used them in a fashion consistently with that meaning. >>>> If you have a proposal that doesn't fit into that taxonomy, then I >>>> suggest >>>> you use a new name, rather than confusing reusing an old one. >>>> >>>> Were Web Developers well-represented when this was first >>>>>> discussed? Do you have a breakdown of who voted in favor or against? >>>>>> >>>>> >>>>> It's in the W3C email archives, meeting minutes, etc. >>>>> >>>>> >>>>> I consider that a non-answer. I have pointed you to a specific >>>>> document that shows that the majority of Web Developers are against the >>>>> current API proposal, complete with a list of names and why they are >>>>> against the proposal. It's not reasonable to ask me to wade through months' >>>>> worth of email archives. >>>>> >>>> >>>> I didn't ask you to do anything. You asked me a question, I told you >>>> how to find >>>> the answer. If you don't feel like doing it, it's hard to see why I >>>> should do it >>>> for you. >>>> >>>> -Ekr >>>> >>>> >>> >> > >
Received on Tuesday, 23 July 2013 04:44:24 UTC