Hi,
I'm not a big fan of this. While on paper a good idea in practice it greatly increases complexity. Mind you that we would need testing, documentation, CI, bug fixing, maintenance for all the various levels.
It also increases complexity on the client side as clients need to check for those levels and adapt their behaviour accordingly. Mind you that JCR exposes its feature via the repository descriptors (something we could probably extend here). But AFAIU most clients simply don't bother and just ignore them.
Regarding the session auto refresh behaviour: AFAIR there is already a way to specify this at session login time. I can dig up the details if this is of interest.
Michael On 28.7.16 10:23 , Stefan Egli wrote:
Hi, Here's an idea that just came up in an offline discussion, not sure if it has been around elsewhere. But we could introduce a concept of 'compatibility levels' which are a set of features/behaviours that a particular oak version has and that application code relies upon. When creating a session by default the 'newest compatibility level' would be used, but applications could opt to use an older, compatibility level 1.2 for example, when they still rely on the feature-set/behaviour oak had at that time. (This could also be based on service-user properties for example.) As such, compatibility levels could be a vehicle to help properly deprecate features over time (when you'd say eg oak 1.10 doesn't support compatibility level oak 1.0 anymore). One concrete case where this could have been useful is the backwards-compatible behaviour where a session is auto-refreshed when changes are done in another session. This seems counter-intuitive given MVCC, but was apparently introduced to remain jackrabbit-2-compatible. (Another slightly different example could be the warn about a session being open for too long without a refresh. This is likely an oversight from an application, but it could also be done on purpose (although I wouldn't know an example right now) - in which case this could be indicated via another flag on the session - but probably doesn't quite fit the compatibility-level approach). Opinions? Cheers, Stefan
