-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP::Server vs ApplicationServer #13072
Comments
This had previously been shortly mentioned in #5776 (comment). In that PR most of the generic application server logic was introduced to So yeah, I think this could make sense. We'd need to develop an API for a generic implementation and how to integrate with the existing |
#13080 is a concrete proposal to implement this. It extracts the generic parts of As a result, The function of A reasonable usage with no part of request_processor = HTTP::Server::RequestProcessor.new do |context|
context.response.content_type = "text/plain"
context.response.print "Hello world!"
end
http_server = NetworkServer.new(request_processor)
http_server.bind_tcp "0.0.0.0", 8080
http_server.listen
This is just to demonstrate the idea. Of course this could use some more polishing to make the API more convenient to use. Take this as food for though. I'm not saying this is the way to go. Maybe keeping the inheritance relationship is actually best. |
The vast majority of HTTP::Server has no specific tie to HTTP.. The various socket binding and such is a standard need for application servers and would appear to be a good fit for another class.
Would there be any objection to splitting off the generic portions of the HTTP:Server into an ApplicationServer class and have HTTP:Server subclass that class? This would make it much easier to stand up a networked server.
The text was updated successfully, but these errors were encountered: