The object that we put into rack.hijack is absolutely part of our public API, so I think you have to call this a breaking change.

Or, the client is initialized with a socket,

I'm not sure I understand this part.

I'm 👍 for this change (though we may want to wait a few weeks to merge, let's let the next release bake a bit and see if it will be Puma 7 or not...)

I see what this does (and if you only call call on this object this change shouldn't be breaking, right?) but can we spell out the benefits/motivation as to why we want to make this change?

@dentarg

I see what this does (and if you only call call on this object this change shouldn't be breaking, right?)

Correct. The only requirement (from the Rack spec) is that the object responds to call. Passing the Client object isn't needed, and the main 'user' items in the Client (env, req.body & and socket) are available in other ways to the user's app.

@nateberkopec

Or, the client is initialized with a socket,

I'll rephrase or just remove.

There are a few env settings that remain the same for the life of the Client object, but current code is setting them on every request, which passes thru the code in Request#handle_request. So, the 'life-time' env setting should be moved to the code in Client.initialize. That's independent of this, so it can/should be a separate PR.

Re the public API, Puma is much better than it used to be. I think minimal public API's are best, as they allow more flexibility with refactors, optimizations, etc. Two considerations though, are they too restrictive for the user, and do they force test code to have too many hacks. I consider things like instance_variable_get to be ok for use in test code.

EDIT: Revised the opening comment