From the oak-dev@ list, here's an early proposal for the overall Oak component structure:
http://people.apache.org/~jukka/2012/oak-components-medium.png
A suggested way of dividing this to actual components (already outdated):
http://people.apache.org/~jukka/2012/oak-components2-medium.png
Whiteboard from a discussion about how the functionality between the JCR and MP APIs should be organized:
http://people.apache.org/~jukka/2012/oak-components3-medium.jpg
Functionality which goes into oak-jcr:
- Transient space: using Microkernel for write ahead
- Name space (re-) mapping: use prefix throughout the stack. Either rename or double dispatch on remapping
- copy, move, import, export
- UUID resolution
Functionality which goes below the Oak API:
- Tree update and access
- Versioning (including mechanism for import)
- ACL evaluation
- Authentication
- Name space map (i.e. the realisation of the map, not the process of (re-) mapping)
- Name and path validation
- Locking?
- UUID map
- UUID validation