Seeing as the current filesystem resource provider does need an update to java 8 api, it would be nice to refactor / start over with that one and make it more generic / extensible? It has some caveats (like the start up scanning etc.) that would be nice to have fixed in a more elegant way.
Roy > On 11 Nov 2018, at 10:55, Carsten Ziegeler <[email protected]> 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 > [email protected]
