Many modern Java Web Server (Netty, Undertow, Vert.x) have their own abstractions for Requests and Responses. Current ring-spec states that requests and responses as map-like structures. While this is awesome in abstraction-wise (and the killer feature of Ring), performance-wise it can be bad as data needs to be copied into maps. Copying can be eager (like with the jetty-adapter) for all requests or lazy (like Aleph & Immutant) / on demand, but still things like accessing a single header value forced all headers to be read copied and keys lowercased.
Abstracting the request and response as protocols would allow best of both worlds. A protocol like:
(defprotocol RingRequest
(get-server-port [this])
(get-server-name [this])
(get-remote-addr [this])
(get-uri [this])
(get-query-string [this])
(get-scheme [this])
(get-request-method [this])
(get-protocol [this])
(get-headers [this])
(get-header [this header])
(get-body [this])
(get-context [this]))
could be implemented for maps so that they do the normal lookup, but the Aleph-style zero-copy-request (map-like) classes could implement those directly. (get-header request "Content-Type") would use the already parsed information without any copying.
This would allow low-level libraries to be programmed against effective protocols while keeping everything compatible with maps.
Currently working on a new lightweight and zero-fat new wrapper for Undertow and using a custom request protocol (like the one above) with it, but would not like to tie our other libraries to a server-specific protocols.
All the current web servers having their own request & response (map-like) types would need to conform to the new protocols, so would be a breaking change.
Many modern Java Web Server (Netty, Undertow, Vert.x) have their own abstractions for Requests and Responses. Current ring-spec states that requests and responses as map-like structures. While this is awesome in abstraction-wise (and the killer feature of Ring), performance-wise it can be bad as data needs to be copied into maps. Copying can be eager (like with the jetty-adapter) for all requests or lazy (like Aleph & Immutant) / on demand, but still things like accessing a single header value forced all headers to be read copied and keys lowercased.
Abstracting the request and response as protocols would allow best of both worlds. A protocol like:
could be implemented for maps so that they do the normal lookup, but the Aleph-style zero-copy-request (map-like) classes could implement those directly.
(get-header request "Content-Type")would use the already parsed information without any copying.This would allow low-level libraries to be programmed against effective protocols while keeping everything compatible with maps.
Currently working on a new lightweight and zero-fat new wrapper for Undertow and using a custom request protocol (like the one above) with it, but would not like to tie our other libraries to a server-specific protocols.
All the current web servers having their own request & response (map-like) types would need to conform to the new protocols, so would be a breaking change.