From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.25.18.86 with SMTP id h83csp751709lfi; Fri, 15 Jan 2016 15:00:17 -0800 (PST) X-Received: by 10.60.231.230 with SMTP id tj6mr10327418oec.8.1452898817384; Fri, 15 Jan 2016 15:00:17 -0800 (PST) Return-Path: Received: from mail-ob0-x23e.google.com (mail-ob0-x23e.google.com. [2607:f8b0:4003:c01::23e]) by mx.google.com with ESMTPS id d1si12865055oeo.79.2016.01.15.15.00.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 15:00:17 -0800 (PST) Received-SPF: pass (google.com: domain of rack-devel+bncBD75LW742ECRBAHU4W2AKGQELVBMF4I@googlegroups.com designates 2607:f8b0:4003:c01::23e as permitted sender) client-ip=2607:f8b0:4003:c01::23e; Authentication-Results: mx.google.com; spf=pass (google.com: domain of rack-devel+bncBD75LW742ECRBAHU4W2AKGQELVBMF4I@googlegroups.com designates 2607:f8b0:4003:c01::23e as permitted sender) smtp.mailfrom=rack-devel+bncBD75LW742ECRBAHU4W2AKGQELVBMF4I@googlegroups.com; dkim=pass header.i=@googlegroups.com; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com Received: by mail-ob0-x23e.google.com with SMTP id x5sf9839524obg.1; Fri, 15 Jan 2016 15:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=ZQq6O2PLDdi7nyWIWhdnl6kprLFthhvv7bP5ro5sFK8=; b=rz4MbQrSKZq5Pvk+FpFgr6WcGm4J+Xqo0RgVsIoudhMSBWMR1AurW3mmHZOKkOSPl4 /RwkzSi1rzANQkzgVytfnBw/dX6N5pEInUCubLHgjdYlm/9x4U3XK+xalg1OxeSsM68U SU32ec9XJTvCtudzpD5bgtxwhWnweCkqNFZAlyS67jt4t9SHENxT1pK6P5UqTBcPOPLA MKAj/FzR+p+NcPyWxdjZqRtTsGMtpDqJWv6l8GQRx+Oypm3klPve4xFAvAbvgCfaX75K shk/vEV9wdZqJbpmWUYBFNd0jXTRR6s7sVgSZdscw+K7J//Ku24KpbNjF5Tfg43IDkxe 1fLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=ZQq6O2PLDdi7nyWIWhdnl6kprLFthhvv7bP5ro5sFK8=; b=jyyxaLfOTG1+l2TWWoXZHo4s0UpIrfsjJyJZVfr+z1w44Yv3ZF8ZliZdQzUZFB0nmt OQY3oPe/NzdHwrQkr33+3e5x3amZ9DtlMIZk15BJNmmkv/ATy9Z2DOtMJ5WSvJkv3AyF QonvRN9wSmcjZNoIT2SIUYspCMc0WVPYy45cOv0E31jUXeEQKoTEcARwCGw3pY3rcN0o nk3psZMurGdjZ6vr+/yPZFm1srFugu9kvp7cjKtUwN5sNGh2eNC6KdlHs88trqX0pcGD FIto1+6konYdz9daQhk2cLK0It+2pI0TcXZYm3Da5obWW9M4/3yxUwYTegf1p5nCb2eu XtSQ== X-Gm-Message-State: AG10YORJa9aPIjCgxsdXhLkcb5pIav85Ue4WZe9cf2rRUUy5pMjKypFJ+bVTBDulboUbnA== X-Received: by 10.50.118.7 with SMTP id ki7mr36991igb.7.1452898816897; Fri, 15 Jan 2016 15:00:16 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.107.25.200 with SMTP id 191ls944556ioz.19.gmail; Fri, 15 Jan 2016 15:00:16 -0800 (PST) X-Received: by 10.50.107.68 with SMTP id ha4mr1169915igb.0.1452898816131; Fri, 15 Jan 2016 15:00:16 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com. [2607:f8b0:4001:c05::230]) by gmr-mx.google.com with ESMTPS id k15si300894igt.3.2016.01.15.15.00.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 15:00:16 -0800 (PST) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4001:c05::230 as permitted sender) client-ip=2607:f8b0:4001:c05::230; Received: by mail-ig0-x230.google.com with SMTP id h5so19323241igh.0 for ; Fri, 15 Jan 2016 15:00:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.138.72 with SMTP id qo8mr933981igb.81.1452898815932; Fri, 15 Jan 2016 15:00:15 -0800 (PST) Received: by 10.36.110.4 with HTTP; Fri, 15 Jan 2016 15:00:15 -0800 (PST) In-Reply-To: <24c6a373-ff9a-452d-bcce-6adaac37d5ad@googlegroups.com> References: <24c6a373-ff9a-452d-bcce-6adaac37d5ad@googlegroups.com> Date: Fri, 15 Jan 2016 15:00:15 -0800 Message-ID: Subject: Re: HTTP2: Are we there yet? From: James Tucker To: Rack Development Content-Type: multipart/alternative; boundary=001a1134c792d183390529675d4b X-Original-Sender: jftucker@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4001:c05::230 as permitted sender) smtp.mailfrom=jftucker@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: rack-devel@googlegroups.com X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , --001a1134c792d183390529675d4b Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 2:28 PM, Tiago Cardoso wrote: > Hi, I've been looking for developments in the rack framework concerning > its update towards great big http2. I've seen the presentation from Aaron > Patterson from October/November, and since then, only seen the events > middleware landing in master. And there's an alpha 2.0 version. > > I assume that http2 won't come with 2.0 . Still, I'd like to know where we > stand, what's missing for rack to develop further in that direction and > where could I help/contribute. Hopefully there's a document someone can > redirect me to. > First of all, the Rack SPEC is not incompatible with http2 today. You can use Rack in an http2 server. What does not exist is new mappings for a server push API. Note that promises (server push) is only additional responses shipped alongside a response. It is not a general IO mechanism. Rack is primarily a framework/interface layer between Ruby webservers and Ruby web applications, as implemented today. That means it's really focused on the HTTP parts, and while http2 can carry other protocols, I would expect that Rack should probably remain an interface layer for http1 over http2, not * over http2. It's conceivable that something could move into such a space, and maybe that could be called Rack, but it would be an entirely different specification, with entirely different goals and complexities. The synchronous single-call design of the Rack SPEC will always be a problem for fuller http2 services (e.g. grpc) as they are not request response protocols and don't fit into that model. In the same way, as that doesn't fit, none of the middleware fits either. I wrote about this years ago. I'm really looking forward to hearing from someone, possibly Mr. Patterson, > who's clearly been working in this. I think ruby needs http2 badly. I think > that all other standards for pushing > server-to-client/full-duplex/pipe-in-my-json will die after widespread > adoption, like image spriting and all those HTTP1 performance > "enhancements". > http2 does not offer full-duplex for web applications today. No browser exposes server push to javascript or anything like that, and even websockets over http2 is as yet undefined - there's only a spec that's been dead for over a year and a half . You can use SSE over http2 today, and if you were using an HTTP2 enabled Rack compatible server, SSE like this would work . In fact, not only "would work", but does work. I use nginx to terminate http2 today, and have http1 rack backends running SSE like this in the wild, and it works just fine. > I think that the ruby frameworks don't need and should not enforce > websockets, specially for thing it was not designed for. I think > ActionCable is crap. And just as Rails, I am entitled to an opinion, and > would like to try to force it into people's throats. And I'd like to force > http2 and consider myself a better human being after that. > I've been down this battle with realtime ruby for years, and so did the author of node before he went and wrote node. That's part of where that came form. The fact that ActionCable relies on EventMachine makes me really quite sad as we've largely stopped maintaining that for important reasons for a long time. The real issue here is that we've never had any good SPEC proposals for specs that handle realtime well, and we have tons of streaming bugs in the core middleware. We fixed a lot of them over the last two years, but I'm sure there are more. Things like the Content-Length and Chunking middleware should *never* have existed, and the fact that they do is an ongoing problem for server authors venturing into this domain. Realtime sockets are also very hard to load balance and scale, and while that might not be actioncables concern, it's a concern for real users in the wild. What most people do today who do this stuff is use external services, rather than putting such things in their monoliths. Users already have very real load balancing problems with high standard deviation response rates and sadly as in the linked example, they often fail to understand the issues here. While some work has gone into better open source load balancers , we still have a long way to go to match up with commercial offerings, and in fact the linked stuff is at least partially commercial only. If you're not using a third party service for realtime persistent sockets, then you'll probably want to use a separate service, because of the many challenges inherent with otherwise muxing it in through your primary serving routes, and indeed that's what we all do. Only thing I found was this: > https://groups.google.com/forum/#!topic/rack-devel/lipvWVZrcfo and after > the author left the project. What's the status? > It's not going anywhere because no one is stepping up to do it. Please understand that stepping up to do it means actually getting something working that works for a wide array of use cases, not just putting your hand in the air and saying "I'll do it" - just that we've seen that many times, even I did that once and I knew better than to volunteer so much of my free time. I don't mean to discourage you though, I would really love to see this happen and if you have the time to start writing test cases and developing a real API for this, I'd be more than happy to provide guidance and feedback. That goes for everyone else too, and it's not the first time I've said it. As with the above, no ones yet taken up the offer. Really appreciate any feedback, > Tiago > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --001a1134c792d183390529675d4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 15, 2016 at 2:28 PM, Tiago Cardoso <honeyryderchuc= k@gmail.com> wrote:
Hi, I've been looking for developments in the rack framework = concerning its update towards great big http2. I've seen the presentati= on from Aaron Patterson from October/November, and since then, only seen th= e events middleware landing in master. And there's an alpha 2.0 version= .=C2=A0

I assume that http2 won't come with 2.0 . St= ill, I'd like to know where we stand, what's missing for rack to de= velop further in that direction and where could I help/contribute. Hopefull= y there's a document someone can redirect me to.=C2=A0

First of all, the Rack SPEC is not incompatible= with http2 today. You can use Rack in an http2 server.

What does not exist is new mappings for a server push API. Note that = promises (server push) is only additional responses shipped alongside a res= ponse. It is not a general IO mechanism.

Rack is p= rimarily a framework/interface layer between Ruby webservers and Ruby web a= pplications, as implemented today. That means it's really focused on th= e HTTP parts, and while http2 can carry other protocols, I would expect tha= t Rack should probably remain an interface layer for http1 over http2, not = * over http2. It's conceivable that something could move into such a sp= ace, and maybe that could be called Rack, but it would be an entirely diffe= rent specification, with entirely different goals and complexities.

The synchronous single-call design of the Rack SPEC will = always be a problem for fuller http2 services (e.g. grpc) as they are not r= equest response protocols and don't fit into that model. In the same wa= y, as that doesn't fit, none of the middleware fits either. I wrote abo= ut this years ago.

I'm really looking forward to hearing from someone, po= ssibly Mr. Patterson, who's clearly been working in this. I think ruby = needs http2 badly. I think that all other standards for pushing server-to-c= lient/full-duplex/pipe-in-my-json will die after widespread adoption, like = image spriting and all those HTTP1 performance "enhancements".

http2 does not offer full-duplex = for web applications today. No browser exposes server push to javascript or= anything like that, and even websockets over http2 is as yet undefined - t= here's only a spec that's been dead for over a year and a= half. You can use SSE over http2 today, and if you were using an HTTP2= enabled Rack compatible server, SSE like this would work. In fact, not only "= would work", but does work. I use nginx to terminate http2 today, and = have http1 rack backends running SSE like this in the wild, and it works ju= st fine.
=C2=A0
I think that the ruby frameworks don't need and should not en= force websockets, specially for thing it was not designed for. I think Acti= onCable is crap. And just as Rails, I am entitled to an opinion, and would = like to try to force it into people's throats. And I'd like to forc= e http2 and consider myself a better human being after that.

I've been down this battle with realtime = ruby for years, and so did the author of node before he went and wrote node= . That's part of where that came form. The fact that ActionCable relies= on EventMachine makes me really quite sad as we've largely stopped mai= ntaining that for important reasons for a long time. The real issue here is= that we've never had any good SPEC proposals for specs that handle rea= ltime well, and we have tons of streaming bugs in the core middleware. We f= ixed a lot of them over the last two years, but I'm sure there are more= . Things like the Content-Length and Chunking middleware should *never* hav= e existed, and the fact that they do is an ongoing problem for server autho= rs venturing into this domain.

Realtime sockets ar= e also very hard to load balance and scale, and while that might not be act= ioncables concern, it's a concern for real users in the wild. What most= people do today who do this stuff is use external services, rather than pu= tting such things in their monoliths. Users already have very real load balan= cing problems with high standard deviation response rates=C2=A0and sadl= y as in the linked example, they often fail to understand the issues here. = While some work has gone into better open source load balancers<= /a>, we still have a long way to go to match up with commercial offerings, = and in fact the linked stuff is at least partially commercial only. If you&= #39;re not using a third party service for realtime persistent sockets, the= n you'll probably want to use a separate service, because of the many c= hallenges inherent with otherwise muxing it in through your primary serving= routes, and indeed that's what we all do.


It's not going anywhere = because no one is stepping up to do it. Please understand that stepping up = to do it means actually getting something working that works for a wide arr= ay of use cases, not just putting your hand in the air and saying "I&#= 39;ll do it" - just that we've seen that many times, even I did th= at once and I knew better than to volunteer so much of my free time.
<= div>
I don't mean to discourage you though, I would reall= y love to see this happen and if you have the time to start writing test ca= ses and developing a real API for this, I'd be more than happy to provi= de guidance and feedback. That goes for everyone else too, and it's not= the first time I've said it. As with the above, no ones yet taken up t= he offer.

Really appreciate any feedback,
Tiago

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
--001a1134c792d183390529675d4b--