Open alexwlchan opened 6 years ago
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:
Last-Modified
header.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
I'm interested in exploring this as well.
A diskless Loris would be awesome
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:
This would be a big change to Loris core, and might not get you anywhere. But I thought worth noting as an issue.