Re: P2P vs client-server (Re: Call for adoption - WEBRTC-QUIC)

On 11/21/2018 05:40 PM, Bernard Aboba wrote:
> Harald said: 
>
> "I disagree with my esteemed colleague; I think that a workable
> client-server solution (as seen from a browser client) is a true
> subset of a peer-to-peer solution, and should have the same API;
> having two different APIs is not terribly useful."
>
> [BA] Agreed. The client-server API is indeed very similar to the P2P
> API, so they need to evolve together.  However, the object naming is
> different (no RTC prefix for the client-server API) and there are
> small changes to the constructor (QuicTransport constructor takes a
> URL as an argument rather than an IceTransport), and to methods (the
> QuicTransport does not need a start method).

Aha - I didn't know that there was already a specific client/server
proposal in the works.

I'd be happy to lose the RTC prefix (for both client/server and P2P) if
that makes life easier for everyone. It's just a name.


>
> A PR for the client-server API is available for inspection, but has
> not landed yet:
> https://github.com/w3c/webrtc-quic/pull/73
>
>
> ------------------------------------------------------------------------
> *From:* Harald Alvestrand <harald@alvestrand.no>
> *Sent:* Wednesday, November 21, 2018 12:21 AM
> *To:* Bernard Aboba; Varun Singh
> *Cc:* public-webrtc@w3.org
> *Subject:* P2P vs client-server (Re: Call for adoption - WEBRTC-QUIC)
>  
> On 11/20/2018 06:08 PM, Bernard Aboba wrote:
>> (with chair hat off)
>>
>> Microsoft is in support of the document, with the understanding that
>> the focus is on peer-to-peer only.  client-server should be a
>> separate document (and may need to be developed elsewhere in W3C).
>
> (chair hat off)
>
> I disagree with my esteemed colleague; I think that a workable
> client-server solution (as seen from a browser client) is a true
> subset of a peer-to-peer solution, and should have the same API;
> having two different APIs is not terribly useful.
>
> We already have an API (fetch) for accessing HTTP over QUIC, which
> fulfils the special requirements for HTTP.
>
>>
>> On Nov 20, 2018, at 8:46 AM, Varun Singh <varun@callstats.io
>> <mailto:varun@callstats.io>> wrote:
>>
>>> We (CALLSTATS I/O)  are in support of this document. 
>>>
>>> And that the scope be limited to QUIC transport, and unidirectional
>>> and bidirectional QUIC streams. 
>>>
>>> Regards,
>>> Varun. 
>>>
>>> On Tue, 20 Nov 2018 at 0.58, Harald Alvestrand <harald@alvestrand.no
>>> <mailto:harald@alvestrand.no>> wrote:
>>>
>>>     *From the Lyon summary of decisions:*
>>>
>>>     *
>>>
>>>     "The WG will ask the list if we should adopt the WEBRTC-QUIC API
>>>     document (in room: 2 opposed, ~10 in favor)"
>>>
>>>     The question is whether we should adopt this document:
>>>
>>>     https://w3c.github.io/webrtc-quic/
>>>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-quic%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C8c0fc59edf3a44ad46a408d64f8a6711%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783853192967472&sdata=Anv993D1NkdoO49VYaaooO177E%2BnfQcdp1T6nLJaQGQ%3D&reserved=0>
>>>
>>>     as a Working Group document
>>>
>>>     Adoption as a WG document does not mean commitment to any
>>>     specific part of the API, or any specific timeline for
>>>     processing the document to CR and beyond, but does mean that we
>>>     can issue the document as a first public working draft (FPWD)
>>>     and ask for IPR declarations (if any).
>>>
>>>
>>>     My personal read is that adoption as a WG document means that
>>>     "we have consensus that there is a problem here that needs
>>>     solving, the problem is within the scope of this WG, and this
>>>     document is a start on the way to solving it".
>>>
>>>     Non-adoption would indicate either that the problem shouldn't be
>>>     solved, that the problem is out of scope for this WG, or that
>>>     this document is so far away from the right solution that it's
>>>     not a starting point the WG wants to consider.
>>>
>>>
>>>     We are seeking both statements of support and statements of
>>>     opposition. The chairs will tally the responses and attempt to
>>>     draw a conclusion.
>>>
>>>     Please state your opinion to the**list on or before Wednesday,
>>>     November 28.
>>>
>>>     Harald*,* for the chairs
>>>
>>>     *
>>>
>>> -- 
>>> Founder, CEO, callstats.io
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcallstats.io&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C8c0fc59edf3a44ad46a408d64f8a6711%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783853192977476&sdata=3t%2FIbHX%2B%2FIPBGHA5ZM%2BHMsxvMcjqzWbjht9ojD3XTwM%3D&reserved=0>
>>> http://www.callstats.io
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.callstats.io&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C8c0fc59edf3a44ad46a408d64f8a6711%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783853192997497&sdata=wHkqYdRhcNGy5bxCDq9nMa9L5JjHG%2BKnZnR%2FhJ44RKE%3D&reserved=0>
>>>
>>> Interested in networking, media quality, and diagnostics.
>>> We are hiring!: www.callstats.io/jobs/
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.callstats.io%2Fjobs%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C8c0fc59edf3a44ad46a408d64f8a6711%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783853193007510&sdata=glaKCJH6bVInDU%2B6Wn1AaaqEijAWUMpjDq91frMejyQ%3D&reserved=0>
>
>