Sorry, but I don't agree on the new added constraints and their conclusion - we should keep constraints and conclusions separate!
- AC1: Waiting for content paths: not all ACLs can be applied immediately when the SlingRepository service starts: for this we'd need to create paths that don't exist yet, and the nodetypes of those paths might not have been defined yet, as any bundle can supply additional node types. This means waiting for the path creation to succeed before proceeding, so we might as well wait for the paths to be created by content installations Again, as already explained there is no content to be installed by bundles. And with service users, the bundles can't create the path as they don't have the rights. For example, discovery reads/writes at /var/discovery. But discovery has no rights to create /var. So again, who is creating this? Requiring additional content for this is wrong and way too complex. We must not forget, that today these bundles are self contained. They work out of the box, regardless if the configuration (path) for them is changed or not as they have admin power and can do whatever is necessary. With service users we remove this. But still it must be simple to use this approach. Someone else needs to create /var for discovery. Nodetypes should be no issue, they can be changed later on. - AC2: The mechanism must work for any launchers, not just the Sling Launchpad - so it cannot be just a build-time thing. Well, maybe "build time" was a wrong term from me. What I mean is that it does not have to be a runtime thing in the sense that it must not be something evaluated when the OSGi framework is started. For example, if we generate something out of the information, this generation can be run within our maven plugin but also by any other launcher. That's easy. Concluding from this requirement that it must be a service running in the framework is wrong. There are many options. - AC3: The full text of the ACL definitions must be available at runtime. This allows for example checking later that a Sling instance is still configured according to those ACL definitions. Again, this is hinting at a particular implementation/solution for the problem. With the current approach this definition is an OSGi configuration which can be changed at runtime. So what purpose does such a check have? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
