Am 05.11.15 um 09:39 schrieb Bertrand Delacretaz: > Hi, > > On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler <[email protected]> wrote: >> ...I suggest we create for each feature a separate bundle with the user >> definition and the ACLs. The stuff gets then installed - like any other >> content - through the contentloader.... > > So taking SLING-5227 as an example (the contrib/bgservlets module) you > suggest (option A) creating a companion bgservlets-users bundle that > provides the user/ACL definitions? > > That would work, but I think my suggestion (option B) is simpler: > include those default definitions in the main bundle, but by default > to not install the service that processes them. > > So by default no users/ACLs are created, and if you want backwards > compatibility or for testing purposes you just install a single bundle > that processes those embedded definitions. > > This means those definitions need to use a different mechanism than > our current contentloader (or maybe a new plugin for that > contentloader) but that's not hard to implement. >
My main point is: how does the developer of the bgservlets know which user to use? Which ACLs to apply? There could be a configuration which changes the default location of the bgservlets stuff in the repository to a different path. (Maybe this is not possible with the bgservlets, but it is definitely true for other bundles). Therefore the developer of the bundle has zero clue and he should not have it. This might be different on every installation. If we put this as a default setting which is not processed in the bundle, assume you have two bundles with such content. You want to have the defaults of one of them but not the other - how do you handle this? That can be dealt with of course, but it adds then another thing on top and makes it much more complicated than it should be. Keeping it separate from the beginning is the clearest way and works in all cases. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
