Rack should be better at auto-requiring unknown handlers
Reported by Graham Batty | February 26th, 2009 @ 10:50 PM | in 1.0
The current behaviour of rack when faced with an unknown handler name is to just fail. For rack to be truly server agnostic, it must allow servers to supply their own implementations without requiring that their patch be included in the rack distribution.
It also makes little sense to create a maintenance headache for the server implementers by requiring that a piece of their code live in an unrelated gem (ie. thin and mongrel already are gems, and should supply their own rack server setup).
To that end, I've written a patch against rack that makes it do some semi-magical requires to try and find an appropriate handler for a name given.
For example, say a new server was written called "BobAndDoug". If a user installs the gem "bob_and_doug", then invokes "rackup -s BobAndDoug", rack should attempt to require "rack/handler/bob_and_doug" before attempting to load the class Rack::Handler::BobAndDoug. (the actual patch included here handles a few more cases as well, you can take a look at their specs if you like)
This should reduce the barrier to entry on making a new server for the ruby world to use and reduce the pressure on the rack project to release new versions just because there's a new server in the wild.
I've put this up on a github branch at http://www.github.com/stormbrew/... as well as the patch included.
Comments and changes to this ticket
-
Graham Batty February 26th, 2009 @ 11:55 PM
IRC channel suggested making it simpler and only accepting FullyCapsedClassNames, so I made that change. Changes are on github as well as in attached patch.
Also made it so that it raises NameError if it can't find the handler chosen. I was finding not doing this resulted in silent failure.
-
manveru March 17th, 2009 @ 05:06 PM
- Milestone set to “1.0”
- Tag set to “handler, lookup, patch, require, review”
- State changed from “new” to “open”
- Assigned user set to “manveru”
I've refactored your patch to be more flexible and adhere to existing file-naming conventions.
I'd love to see this in Rack before 1.0 to allow new servers to gain popularity without a need to adapt rack to every new kid on the block.
+1
-
Graham Batty March 20th, 2009 @ 10:30 AM
The original patch actually did allow for the existing naming convention and a much more flexible naming, but I was warned off it on IRC by ... chris2 I think?
Not opposed to making it more flexible, but I'm not sure I understand what the official position is on that :)
-
manveru March 23rd, 2009 @ 02:48 AM
I don't think there's an official position on this issue.
My reasons for the additional change is to make reuse easier and outcome more predictable.
I have used the same kind of try_require for plugins and similar things in a few applications already, since Rack now needs the same funcionality it just makes sense to make it usable from elsewhere.
I've found problems with the way you did the snake-casing with existing handlers like WEBrick and FastCGI, they become 'w_e_brick' and 'fast_c_g_i' respectively, that's why i rewrote that part.
If you have no objections to my changes within 2 days I'll push it into the master branch.
-
Graham Batty March 26th, 2009 @ 05:39 AM
As long as it generally achieves the goal, I'm fine with it.
-
manveru March 26th, 2009 @ 05:58 AM
- State changed from “open” to “resolved”
I pushed the changes to master branch
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
manveru