[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250750#comment-13250750
]
Thomas Mueller commented on OAK-56:
-----------------------------------
> I guess this should be better approached from the top instead of from the
> bottom.
For some things are easier if you use a service provider interface. Java itself
uses the service provider interface quite a lot. We had a file system
abstraction in Jackrabbit 2.x, unfortunately we didn't use it in many cases.
Please note Java 7 has a file system abstraction as well, and the proposed API
is very similar to Java 7. Once Java 7 is the minimum requirement we can remove
our own abstraction and use the Java features. But I guess we will have to
support Java 6 for quite some time still.
> Do we want to implement a MK with features like the ones you describe?
Yes. We have to, if we want to replace CRX 2.x without losing features. Of
course we can implement the whole MK stack again in CRX, *with* the
abstraction, but I think that's kind of pointless (specially for the data
store). Or we can do it as we did in CRX, that is, implement the features
without using an abstraction. But I would like to avoid that, because this
resulted in a non-optimal and very inflexible solution.
> Do we want to implement a MK with features like the ones you describe?
> If yes, should that be the default implementation included in oak-mk or a
> separate component?
Yes, that's what I propose.
> File system abstraction
> -----------------------
>
> Key: OAK-56
> URL: https://issues.apache.org/jira/browse/OAK-56
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mk
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Priority: Minor
>
> A file system abstraction allows to add new features (cross cutting concerns)
> in a modular way, for example:
> - detection and special behavior of out-of-disk space situation
> - profiling and statistics over JMX
> - re-try on file system problems
> - encryption
> - file system monitoring
> - replication / real-time backup on the file system level (for clustering)
> - caching (improved performance for CRX)
> - allows to easily switch to faster file system APIs (FileChannel, memory
> mapped files)
> - debugging (for example, logging all file system operations)
> - allows to implement s3 / hadoop / mongodb / ... file systems - not only by
> us but from 3th party, possibly the end user
> - zip file system (for example to support read-only, compressed repositories)
> - testing: simulating out of disk space and out of memory (ensure the
> repository doesn't corrupt in this case)
> - testing: simulate very large files (using an in-memory file system)
> - splitting very large files in 2 gb blocks (FAT and other file systems that
> don't support large files)
> - data compression (if needed)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
