I've thought about these issues too.

I don't think there is anything wrong with Rack. It could be tidied up a 
bit and it's good, IMHO, that it's entered maintenance mode. Not much needs 
to change IMHO. It's solid. Big changes here will only cause chaos.

In my mind, HTTP2 is more about communication between client and front-end 
server. If the application server implements HTTP1 that's fine. Let's face 
it, in production we don't usually use Rack to serve static files, etc.

Additionally, in my mind, an HTTP application server is no place for 
real-time communication. They are two separate concerns. For example, we 
have a real-time web chat system which implements a real-time run-loop 
using multiple event-driven reactors. It still communicates with a backend 
database using the same code as our application server, but it works in a 
way which can scale to 1000s of active connections per instance.

I think that trying to shoehorn these orthogonal concerns into Rack is 
probably a bad idea in general and will just destroy the original beauty of 
`response = app.call(env)`.

I'd prefer to see Rack evolve in a way which makes it better as an 
application server for request/response type workloads. If we need to 
augment that with something else, let's figure that out in a different 
framework?

-- 

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