What does diskless Loris look like?

[alexwlchan]

Right now, Loris does a bunch of work passed images around the file system: downloading to tempfiles, caching derivatives, and so on.

What if it… didn’t?

Reasons I think this might be interesting:

• If you run CloudFront or a similar cache in front of Loris, derivative caching via local FS is a waste. Better to pass the raw bytes straight out.
• if you have a slow local disk, an HTTP resolver might be faster.

This would be a big change to Loris core, and might not get you anywhere. But I thought worth noting as an issue.

[jpstroop]

This has come up several times, but I'm surprised to see that there isn't an issue for it. This was actually always my intent, but the use case never fully materialized and so the work never really happened.

I don't think it's as big a change as you might think. The enable_caching config option was put in to serve this purpose, and should be the only hook you really need to to decide whether to cache on Loris's filesystem or not. I have a feeling though, that when this is set to False the application may not be sending the headers that a front-end cache would require. A few other thoughts:

1. It might be cleaner to hash a concatenation of the time the source file was last modified and the canonical form of the request to create an ETag than all of the ugly time comparisons that happen now to build a Last-Modified header.
2. Even with no cache behind Loris, I think you'd still want to cache the image info in a dict in memory--maybe some kind of LRU OrderedDict--as this is needed for every single image request, and e.g. a tile/deep zoom viewer would force the server to extract it several times from the same image repeatedly.

/cc @demiankatz

[jrhoads]

I'm interested in exploring this as well.

[minusdavid]

A diskless Loris would be awesome