Replies: 1 comment 5 replies
-
I think
While that is a focus, it isn't the sole focus. Otherwise, Rack would only ship Lint/SPEC. If we want to have a gem just focused on the interface, we should spin out rack-lint as a separate gem, and make rack depend on it (not in favor of that approach, though).
Servers that depend on Rack the interface don't need to require the rack gem at all. The beauty of the rack interface is that it just uses common ruby objects, instead of rack-specific objects.
While theoretically possible, the more likely scenario is rackup being sent out to pasture to die. How much has rack-session improved since being removed?
The tests will likely be just as flaky if rackup is moved to a separate gem, it just makes the problem less visible.
The issue there is that other than webrick, the servers maintain their own handler. However, I'm not opposed to testing additional servers in CI.
This is something that would could specify.
If handler registration is left in rack, it really doesn't make sense to move rackup out, IMO. |
Beta Was this translation helpful? Give feedback.
-
I would like to propose we move
rackup
,Rack::Server
and theRack::Handler::*
to a separate gem.Rack
the interface also getrackup
the executable.rackup
at a different release cadance fromrack
.rackup
tests have been flaky.We should leave handler registration in Rack, at least for the short term - and define a better interface (at least a standard for
#stop
) for servers to follow.Beta Was this translation helpful? Give feedback.
All reactions