>From my experience working with customers, I can pretty much guarantee that sooner or later:
(a) the implementation of an automatism is not *quite* what they need/want (b) they want to be able to manually select (or more likely override) whether a file can be archived Thus I suggest to come up with a pluggable "strategy" interface and provide a sensible default implementation. The default will be fine for most customers/users, but advanced use-cases can be implemented by substituting the implementation. Implementations could then also respect manually set flags (=properties) if desired. A much more important and difficult question to answer IMHO is how to deal with the slow retrieval of archived content. And if needed, how to expose the slow availability (i.e. unavailable now but available later) to the end user (or application layer). To me this sounds tricky if we want to stick to the JCR API. Regards Julian On Mon, Jul 3, 2017 at 4:33 PM, Tommaso Teofili <tommaso.teof...@gmail.com> wrote: > I am sure there are both use cases for automatic vs manual/controlled > collection of unused data, however if I were a user I would personally not > want to care about this. While I'd be happy to know that my repo is faster > / smaller / cleaner / whatever it'd sound overly complex to deal with JCR > and Oak constraints and behaviours from the application layer. > IMHO if we want to have such a feature in Oak to save resources, it should > be the persistence responsibility to say "hey, this content is not being > accessed for ages, let's try to claim some resources from it" (which could > mean moving to cold storage, compress it or anything else). > > My 2 cents, > Tommaso > > > > Il giorno lun 3 lug 2017 alle ore 15:46 Thomas Mueller > <muel...@adobe.com.invalid> ha scritto: > >> Hi, >> >> > a property on the node, e.g. "archiveState=toArchive" >> >> I wonder if we _can_ easily write to the version store? Also, some >> nodetypes don't allow such properties? It might need to be a hidden >> property, but then you can't use the JCR API. Or maintain this data in a >> "shadow" structure (not with the nodes), which would complicate move >> operations. >> >> If I was a customer, I wouldn't wan't to *manually* mark / unmark binaries >> to be moved to / from long time storage. I would probably just want to rely >> on automatic management. But I'm not a customer, so my opinion is not that >> relevant ( >> >> > Using a property directly specified for this purpose gives us more >> direct control over how it is being used I think. >> >> Sure, but it also comes with some complexities. >> >> Regards, >> Thomas >> >> >> >>
