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.