- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Mon, 22 Jul 2013 11:38:00 -0400
- To: Kiran Kumar <g.kiranreddy4u@gmail.com>
- 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: <51ED51D8.1030202@bbs.darktech.org>
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 <mailto: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
> <mailto:piranna@gmail.com> <piranna@gmail.com
> <mailto: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
> <mailto:ekr@rtfm.com>> escribió:
>
> On Sun, Jul 21, 2013 at 7:41 PM, cowwoc
> <cowwoc@bbs.darktech.org <mailto: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 Monday, 22 July 2013 15:38:54 UTC