> From my perspective as an Oak user I would like to have control on that. > It would be nice for Oak to make *suggestions* about moving things to > cold storage, but there might be application constraints that need to > be accounted for.
That sounds reasonable. What would be the "API" for this? Let's say the API is: configure a path that _allows_ binaries to be migrated to cold storage. It's not allowed for all other paths. The default configuration could be: allow for /jcr:system/jcr:versionStorage, don't allow anywhere else. This could be implemented using automatic moving (as I have described), _plus_ a background job that, twice a month, traverses all nodes and reads the first few bytes of all nodes that are _not_ in /jcr:system/jcr:versionStorage. The traversal could additionally do some reporting, for example how many binaries are were, how many times where they read, how much money could you save if configured like this. For automatic moving, behaviour could be: - To move to cold storage: configuration would be needed: size, access frequency, recency (e.g. only move binaries larger than 1 MB that were not access for one month, and that were accessed only once in the month before that). - When trying to access a binary that is in cold storage: you get an exception saying the binary is in cold storage. Plus, if configured, the binary would automatically be read from cold storage, so it's available within x minutes (configurable) when re-read. - Bulk copy from cold storage to regular storage: This might be needed to create a full backup. We might need an API for this. Regards, Thomas
