From: karl@kleinpaste.org   
      
   On 03/08/2018 05:14 PM, ElChino wrote:   
   > Would it not make more sense to support this in some kernel-driver?   
      
   Did you watch the video?   
      
   He explains the motivation reasonably well for a short video: The   
   priorities being considered are very application-specific.   
      
   Certainly it's possible that a generalized QUIC implementation for the   
   OS could be produced which has options for a variety of arbitrary kinds   
   of these applications (basic web page service -vs- email access -vs-   
   file transfer -vs- audio/video 1-way -vs- audio/video N-way interactive   
   -vs- ...), and then the applications written to use QUIC could specify   
   which of these generic profiles are desired. Offhand, and without   
   thinking it through too far, I envision this as a socket option kind of   
   concept, which unfortunately is where all the random crud like   
   TCP_NODELAY gets dumped for protocols; similar socket options named   
   QUIC_EMAIL and QUIC_XFER and so forth would at least fit there in a   
   somewhat orthogonal sense.   
      
   Insofar as they're apparently in the midst of experimenting, I can't say   
   I'm surprised that they're staying high up in application space so far.   
      
   It would be nice if, after having experimented for some time inside   
   Chrome and friends, Google could provide such a kernel implementation   
   plus some proof-of-concept reference applications that are written just   
   to show off what the protocol can do.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)