Hi, Is configuration part of application content or system content or both?
I can see that in a clustered environment you might want to have configuration shared centrally amongst many versions of the running application, but you might also need configuration local to a running version, so that upgrades don't require all running instances to be taken offline. Best Regards Ian On 18 August 2014 10:12, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi, > > I'm working on various experiments (like [1]) related to continuous > deployment with Sling, and having a clearer definition of the various > roles of the content that a typical Sling applications manages would > help. I'm saying "roles" instead of "types" on purpose, to avoid > confusion with Content-Type ;-) > > There's a lot of ties between this and our recent discussions about > multi-tenancy, so refining this tentative list of roles might help for > that as well. > > Does this list fit with your use cases? Do people see other roles? > > My context is a number of Sling instances sharing a common content repository. > > Deliverable content: > Displayed on a website or mobile app for example. > Can be global, shared between a group of tenants or tenant-specific. > > System content: > Defines how a specific version of the system behaves. > Multiple system versions can coexist in a shared content repository > (as we demonstrated in [1], in a limited way) > > Application content: > Extensions or overrides of system content, that modify how the system behaves. > Usually tenant-specific, or maybe shared between a group of tenants > > Module state content: > The typical example is workflow models and state, which is not > deliverable but persistent and might be partially shared. > > Instance-specific transient content: > Transient content that's relevant to a single Sling instance. Compiled > scripts, for example. > Not needed when the Sling instance starts. > > WDYT? > > -Bertrand > > [1] https://github.com/ArtyomStetsenko/sling-devops-experiments
