Re: Proposal: Different specifications for different target audiences

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