sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Simple File System Resource Provider
Date Mon, 12 Nov 2018 10:50:48 GMT
It's only 1 - 2 from your list is taking a structured json and creates 
resources out of the structure (if I'm not mistaken) which is something 
I don't need.

With the approach I hope there is no need for b) (caching) as the 
mapping is 1:1 (more or less). As there is no need for cachign I don't 
think a) is needed either.


Am 12.11.2018 um 11:23 schrieb Stefan Seifert:
> 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 []
>> Sent: Monday, November 12, 2018 11:20 AM
>> To:; 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]
>> file-system-resource-provider.html
>>>> -----Original Message-----
>>>> From: Carsten Ziegeler []
>>>> 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
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland

Carsten Ziegeler
Adobe Research Switzerland

View raw message