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]
