Some questions regarding the RackSpec idea presented here.

[radanskoric]

I really like the idea presented here of using the request and response objects and defining as little of their API as needed. I especially like the idea of a RackSpec (mentioned here: https://github.com/tenderlove/the_metal#tests), it seems to me it could provide a great balance between a common interface and great freedom for specific implementations to provide extra features and optimizations.

Am I right in thinking that if we were to theoretically take this idea to the very extreme rack could be just a set of specs for servers and frameworks to ensure compatibility and actually not have any code of it's own? So the interface would be imposed implicitly by running the spec suite against servers and frameworks?

But then of course we'd want to take it back just a bit to provide code for common functionality to be shared between implementations and to have just enough glue code to allow rack to provide some standard hooks into the request lifecycle?

If my thinking is correct then would the most important next steps be writting the RackSpec to codify all the ideas about the interface and providing the default implementation like the one @tenderlove provided here?

[Wardrop]

Rack is already "just a spec". The Rack framework (as opposed to the Rack spec) provides handy boilerplate, but you don't by any means need to use it, it's just that most (if not every) framework uses it, so unless you write your own framework or application without using the Rack framework, well, there's no avoiding the Rack framework.

Any Rack replacement needs to be defined as a specification the same as Rack, but to gain any sort of traction there's needs to be an accompanying framework or toolkit for application and/or framework developers to build on-top of. At the very least, their needs to be some code as a working example which people can play with.

[radanskoric]

@Wardrop, not sure if this was clear, but when I said "just a spec" I meant a test suite so comprehensive that it covers every aspect of Rack 2.0 and it can be easily run by Servers and Frameworks to verify validity.

I'm basically interested in what would be the best way to contribute towards making this a reality. I see that this and your Rack-Next repo (by the way, great effort there, thank you) are a bit dormant now. If one was to send a pull request to this repo to move it forward, what would be the most useful contribution?

[w-A-L-L-e]

Cool concept! Haven't found time to test this thoroughly but like the concept. I noticed sinitra (sinatrarb) had a good performance advantage over rails as a whole but that was way back in the 2.3.x days haven't had time to compare it vs rails 4.

[zotherstupidguy]

I am a bit confused by "A middleware framework should not be defined by Rack 2.0."

I think this was an awesome thing to have in rack and it enabled the development of a lot of cool projects. If rack is to be without a middleware framework, frameworks build on rack will need to have this reinvent the wheel code in them. A plugin system is needed in almost all of the frameworks build on top of rack.

[zotherstupidguy]

@tenderlove lose the "the", just "zmetal" :+1:

[w-A-L-L-e]

@zotherstupidguy Didn't want to diss rack or something. Rails and pluggable middleware(s) are indeed nice to have. Just for like a simple api or something sinatra rb works also. Like said, I have no idea if it's even still a bit slower on rails 4, didn't even test this. Sorry if I offended someones work on middleware here, that was not the intention at all.

[Wardrop]

@radanskoric I believe the best way to move forward on this is to start pumping out proof of concepts, as tenderlove has done, and as I need to do for the Rack-Next project. It's hard to move forward on higher level stuff until we know how the spec will work at it's lowest level, in terms of streams, etc, and the only way to lock that in stone is to try out different ideas and see which one seems to work the best.

[radanskoric]

@Wardrop Yes, I think you're right. Makes a lot of sense.

[zotherstupidguy]

@w-A-L-L-e no problem at all! I'm just pointing out that the need for this middleware or that "Layers" architectural pattern that proved to be beneficial, needs to be addressed somehow; maybe even by a separate project ! I agree with @Wardrop that experimenting is the best thing to do at this stage.

Software design is tricky, and a lot of smart ppl talk about it, recently Domain-driven design gained a lot of popularity and in my opinion rails ppl are struggling with it. And even that Rack belongs to the Domain of the web, there are rack middlewares that utilizes different domains knowledge and make it available to the application as every software application needs a number of domains to provide a decent functionality.

I can see that making rack strictly a specification and moving the middleware thing into another separate project would be of value. And as a matter of fact I actually experimented with this concept about a year ago, and in theory it works very well!