Filters can create new arbitrary data against incoming uploads (previews for large images) and downloads (conversion and cache file format) but the filter framework doesn't have access to @metastore, @filestore, or @config.
This is by design, as direct manipulation/storage of resources would overcomplicate error edge cases, or force them to be re-implemented for each filter. (For example, filestore quota checks.)
Filters will need to:
- Only create new content when appropriate
- conversion filters need to check to see if the conversion already took place in
the past, and offer the cached copy instead of re-generating
- Optionally mark content as volatile
- An image preview would probably be static, as applications might rely on its existence. A resource that is a differing format (a jpg version of a png) that could be regenerated would be marked as 'volatile', for a potential future cleanup sweep from an admin handler or something.
- Or just to answer the question, "how much space is the filestore using in data that is cache?"
- Signal that new content is waiting somewhere for addition
- Perhaps storing stuff in the response.data scratch space, for daemon/defaulthandler
to pick up on and do the actual storage after the original upload is successful -- or...
- A new ThingFish::Cache class, that acts as a bridge from Filters to storage. By default, all our volatile data will be stored in the regular FileStore?. Abstracting it out would allow volatile stuff to be dumped directly into something like memcache.
