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

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

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>