Fork me on GitHub
#ring
<
2019-05-09
>
mpenet15:05:14

@ikitommi Surprising. But I meant you could write your own version of derived-map that's basically a simple wrapper for map functions (assoc/get/dissoc) with an inlined switch on the correct piece of code and fallback on normal fns for extras (like extmap for records). But yeah protocols are easier but I have the feeling that's not something that would be added to ring without resistance (I could be wrong)

mpenet15:05:44

also I imagine some adapters might not do caching of the returned values (ex when parsing headers) while others do. So sometimes acting as a simple method proxy might not be the best thing to do, but I guess that's a concern for the implementer of the protocol (or whatever is used)

ikitommi15:05:09

the def-derived-map seems to emit fast access functions for all fields (`.get__0`...). Immutant exposes the ServerExchange as a key so we could extend the Immutant Request Type to satisfy a new common protocol. I think this is best of both worlds: a map-like request to be compliant with the ring spec, a zero-copy construction and can be used via (the new) protocols for really fast access.

ikitommi16:05:03

Could add the new protocols to in reitit-ring and rewire the internal middleware & interceptors to use those. And a new reitit-immutant module to make it fast with Immutant.

ikitommi16:05:12

Aleph doesn't expose the Netty Request, so would need a PR for it to work. Could try that after seeing if the perf gains are visible in the real usage.

ikitommi16:05:51

getting the protocols into ring.... Wouldn't break anything and the default would be to make maps satisfy those. Would like to hear what @weavejester thinks about this.

ikitommi16:05:30

btw, didn't know about __extmap, thanks.