so from my list below your use case is 1. + 2. + a) + probably b) and leaving out the other parts? or something different from what is implemented currently?
stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Monday, November 12, 2018 11:20 AM >To: [email protected]; Stefan Seifert >Subject: Re: [RT] Simple File System Resource Provider > >Hi, > >I would be totally happy if we can factor out the extensions, I'm >wondering however if this is worth the effort. > >In my use case, I would like to have a simple mapping to directories and >files, supporting json and binary files. So a resource maps to a json >file 1:1 regardless of the structure of the json file and a such a >resource can have an additional binary. > >I understand the need for the support of all the other features we have >today, but they are not needed for other use cases. > >Regards >Carsten > >Am 12.11.2018 um 11:06 schrieb Stefan Seifert: >> yes, the current implementation of the fsresource provider is no longer >any simple. >> >> it currently supports three (configurable) modes: >> 1. simple mapping of folders and binary files from filesystem (this was >the starting point of fsresource) >> 2. reading structured resource data from JSON files and folders in the >same way it is done by the content loader >> 3. reading structured resource data from FileVault XML files as it's >stored in content packages >> >> and features: >> a) sending resource events if any of these files are changed in runtime >> b) implement some caching to speed things up >> c) support not only the Sling Resource API, but also simulate an >underlying JCR API for code that runs on top which is still using the JCR >API for cases where also the Sling Resource API would suffice but cannot be >changed because it's part of a product... >> >> so the use case ranges from simple mapping of a bunch of static files to >full-blown emulation of a JCR repository out of a complex project structure >in the filesystem e.g. for usage in a development environemnt (see [0]). >> >> --- >> >> removing the embedded json libraries should be simple, it was only for >convenience when the fsresource bundle is to deployed afterwards to an >existing instance. >> but the dependencies to all those JCR-related bundles remains as long as >all three modes and features need to be supported. >> >> i'm not sure if implementing a new fsresource provider e.g. only for >1.+2. from scratch would be the best way. there is a lot of special logic >for edge cases esp. in 2. to make sure it behaves the same as the content >loader which we have then to duplicate another time. it should be possible >to split the existing fsresource into a core and extension bundle as it's >somewhat separated already due to the different supported modes 1./2./3., >and the virtual JCR API support could be made configurable as well. >> >> supporting Java 8 features for the filesystem changes detection would be >a good thing; last time i was looking into it i failed to make good use of >it due to strange implementation differences on windows and unix file >systems (and those differences where covered by the JavaDocs). but maybe >there is a way to do it right. >> >> stefan >> >> [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling- >file-system-resource-provider.html >> >> >> >>> -----Original Message----- >>> From: Carsten Ziegeler [mailto:[email protected]] >>> Sent: Sunday, November 11, 2018 10:56 AM >>> To: Sling Developers >>> Subject: [RT] Simple File System Resource Provider >>> >>> 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] >> > >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
