Currently, the caches use OS specific paths (such as \SubDir\File.txt on Windows) as a cache key. This is reasonable but adds some additional complexity to consuming frameworks:
- Frameworks will most likely have a HTTP route, which will always use slashes as separator characters
- Frameworks may not have a leading slash so it must artifically be added
- Frameworks have a binary representation of the request URI (for example
ReadOnlyMemory<byte>), so they need to allocate a string from that
A simple improvement for 1 & 2 could be a path normalization that removes the leading slash and uses a slash as a separator.
For 3 we could use a specialized readonly struct as a cache key. However, frameworks have an encoded URI (which may contains things like %2C), so either the framework or the library has to translate URI paths to file paths. Not sure where this is best implemented and whether this is possible allocation free at all ..
Currently, the caches use OS specific paths (such as
\SubDir\File.txton Windows) as a cache key. This is reasonable but adds some additional complexity to consuming frameworks:ReadOnlyMemory<byte>), so they need to allocate a string from thatA simple improvement for 1 & 2 could be a path normalization that removes the leading slash and uses a slash as a separator.
For 3 we could use a specialized
readonly structas a cache key. However, frameworks have an encoded URI (which may contains things like%2C), so either the framework or the library has to translate URI paths to file paths. Not sure where this is best implemented and whether this is possible allocation free at all ..