Clojurians Log v2
ring
could the next version of Ring be based on protocols? e.g. Request and Response protocols. Maps could implement this, so one could use it as before, but it would enable faster processing in libraries:
1) request comes in (via Immutant), does a zero-copy request proxy, implementing the ring protocols (now: own custom protocols for this) + map interfaces so it can be used as a map
2) when a request needs to be inspected in a routing / middleware / web library - it coud use the protocols like (ring2.core/get-uri request) & (ring2.core/get-request-method request), which would basically translate to direct java method calls to Undertow Java Request implementation => much faster, no need to realize the full request maps if they are not used
3) apps could choose to use the map-syntax or the protocol-syntax
You can turn the problem around and use a request/response ds that "behaves" like a map but only realizes (and potentially caches) the values as requested
potemkin had something like that
seems to be what aleph is doing on some parts too: https://github.com/ztellman/aleph/search?q=def-derived-map&unscoped_q=def-derived-map
Copied that to my immutant(-nio) fork too (https://github.com/ikitommi/immutant/blob/master/web/src/immutant/web/internal/undertow.clj#L226-L244). I think it’s a good approach, but there is still a extra hop (and internal cache) between the caller and the data. Could bench that out, but an exposed protocol would be truely zero-fat.
but, true, it would be less intrusive to do that behind the scenes (like those two web servers do it today)
should be quite close, it's just a method call that calls another method under the hood
I guess the jvm might do some magic to remove the overhead after a while
could be, I did some benching while ago, could rerun.
(I am not super familiar with the internals of derived-map, but you could simplify it to the strict minimum and tune it to that use case)
I’ll run some numbers and get back. thanks for the thoughts