Sling does not mandate anything to be mutable or immutable. Products build on top of Sling however might do. Ruben has noted that the solution he is working on is immutable with respect to /apps and ours is, too. That is for production systems - not development systems.

As noted, a mechanism like proposed here (or the superimposing one) makes sense to me in general. But in my opinion it creates problems with solutions having parts immutable. Again that's of course a decision everyone can make for themselves. Still my suggestion for everyone having an immutable part in the repository would be to look for a less intrusive solution

Regards
Carsten

Am 27.04.2021 um 01:06 schrieb Cris Rockwell:
Where are the docs about making apps completely immutable? Sounds like it
would be huge pain to be a site (customer) developer for a system like
that.


On Fri, Apr 23, 2021, 1:32 AM Carsten Ziegeler <cziege...@apache.org> wrote:

Thanks Ruben,

in my opinion /apps belongs to developers. In our case its immutable for
good reasons. Drilling a hole into this and allowing non developers
contribute to /apps, especially in a dynamic fashion circumventing the
immutability sounds very risky and can result in security problems.

I understand that extra configuration options are added to partially
address this, but then it comes down to how effective these are and what
holes they might have.

Now, in general I'm not against a feature like dynamic resources - but
making something immutable mutable especially for a different audience
is too dangerous.

Regards
Carsten

Am 22.04.2021 um 18:27 schrieb Ruben Reusser:
Carsten,  see inline

On 4/22/2021 6:55 AM, Carsten Ziegeler wrote:

Am 21.04.2021 um 15:30 schrieb Ruben Reusser:
- for each website that is created we have to create a corresponding
/apps folder for rendering purposes

I assume the ddr solution is temporary and eventually the information
is added to /apps directly? In this case I would do that immediately.

we try to live in a composite nodestore world where /apps is not
writable - so no, we can't write to apps when creating a website

- we also want to give editors a certain control over group names,
labels and the component variations an editor can pick from when
creating a page

That sounds as if that is part of content not stored in /apps?

the default node structure we want to create if a user adds a component
to a page is currently under apps but we would like to keep it somewhere
in /content in the future

our big motivation for DDR is to make authoring and maintaining a
website less dependent on developers and allow for better customization
options after the initial effort to build a site has been completed.

Carsten

Ruben

--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org



--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Reply via email to