+1 for creating a "simple" FS resource provider with _pluggable_ formats. Maybe it doesn't even need to be FS specific? Just "simple" :)
Things like a mock JCR implementation are very useful for some use-cases, but IMHO they could also be achieved with a custom adapter factory and thus be highly decoupled. Resource event support is probably harder to decouple, but could be configurable (on/off). When I last used the FS RP, I found that it was lacking stable child iteration order - I think thjis may be desirable for a new "simple" RP as well. For the FS RP I made this alphabetical for file-based resources. Resources defined withion an XML/JSON file retain the order in which they are read. Regards Julian On Mon, Nov 12, 2018 at 3:13 PM Jason E Bailey <[email protected]> wrote: > > +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 > > [email protected]
