> Should "rack" be called standard-http-server-api-with-support-for-middleware, and then "unicorn" be called pre-forking-web-server-using-standard-http-server-api-with-support-for-middleware?

No, but perhaps we could have:

    WebServer = require_any_satisfying_protocol 'http-server/with-middleware-support'
    WebServer.new

where each rubygem installed has a table of protocols each of its classes and modules support. For example, Mongrel would have a table that starts:

    {Mongrel::HttpServer => ['http-server', 'http-server/with-middleware-support']}

There are two problems with that.

1. In practice you almost never want to load a random library that says it supports a certain interface, you will want a specific library. Notable exceptions are glibc where the interfaces are well-defined over several decades but that brings us to...

2. Few libraries implement the same exact interface. Mongrel and Unicorn have totally different interfaces. Phusion Passenger is also a web server but works in a fundamentally different way from either of them. Hpricot and Nokogiri are both XML parsers but their usage API is different.

Thus, I imagine, why djacob's link to HTTPI talks about protocol adapters, rather than expecting the implementations to adhere to the protocols directly. Still, the adapters could come with each protocol-supporting gem, rather than being housed in some third party "interface library." Then we could have something more like this in each class of a gem:

    class Mongrel::HttpServer
      class HttpServerProtocolAdapter < Gem::ProtocolAdapter
        implements 'http-server'
        implements 'http-server/with-middleware-support'
        ...

and the manifests (which would then look more like this:)

    {'http-server'                         => Mongrel::HttpServer::HttpServerProtocolAdapter,
     'http-server/with-middleware-support' => Mongrel::HttpServer::HttpServerProtocolAdapter,
     ...}

would be generated automatically at gem installation by loading the gem and then probing for ProtocolAdapter instances in ObjectSpace.

Of course, if you had a class that matched the protocol exactly, you could just use something like

    class Mongrel::HttpServer
      supports_protocol 'http-server'
    end

and be done with it.

This is all assuming that we don't actually want our protocols to be modules or classes or something else that we have to include in the adapter somehow (because this is Ruby, and we do well without needing IDuck.) Instead, protocols would just be externally specified things, with their name-strings perhaps being the URIs of standards docs. At most, if a Gem::Protocol was a reified type, it would be a unit test suite to determine whether a ProtocolAdapter actually supported its protocol (minimally, via a series of #respond_to?s.)

There are hints of efforts in this area. See rubyinterfaces.com.

As an example, their proposed HTTP interface can be found here:

http://rubyinterfaces.com/httpi-0.1.0/