+1 on a simple resource provider, I'm curious about the focus on a filesystem provider. I've started playing around with creating one and I see a clear logical association between what a resource provider needs and a key-value store. Good key-value stores already have versioning, and non blocking read and writes. Things that are architecturally nice to have removed from our hands.
Something like mvstore - http://www.h2database.com/html/mvstore.html or lmdb - https://symas.com/lmdb/ would be really good to build on. - Jason On Sun, Nov 11, 2018, at 4:55 AM, Carsten Ziegeler wrote: > I've recently tried to run a minimal Sling without JCR. Obviously you > need at least one resource provider to have some content, so I picked > the easiest choice, the file system resource provider. > > However, it turned out that this is not the easiest choice for this > scenario as it has a lot of features, especially support for handling > content XML files and vault files, which again brings in the whole > dependency list to jcr related bundles. In my case I just want to stream > binaries and json files, so none of the above is needed. But still I > need to deploy all the bundles. In addition there are other things like > the json parsing library is embedded in the bundle etc. > > Now, I think we should really have a simple file system resource > provider which only does the basics and has not an endless list of > bundles. I see two ways to get there: make the current provider > extensible and provide all this extra cruft as extensions or write a new > simple provider. > > Thoughts? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
