Hi all,
I think the current proposal makes sense and deals with the deployment concerns
of service users. Would it make sense to express also the development
requirements for services? I know that has been discussed over and over again
but I wonder if instead of choosing one variant over another we could actually
have both.
1. Deployment definition of service users and ACLs (defined by a "deployer”)
- this is a provisioning concern and is what Bertrand is proposing
(create user, add remove ACLs)
2. Development definition of services and their requirements (defined by a
developer)
- this a a bundle concern and is a definition of services (not of
users) and their needs
- it does not say how to get there (create user, add acls, …) just what
it needs
- someServiceName require read on somePath
- someServiceName optional write on somePath
Some advantages of a separate specification of required capabilities would be
1. The developer focuses only on what its code needs, not on how to install
them (this becomes smoking of "content access API").
2. A tool can pick up the development requirements and install them (this can
be used at least for testing).
3. A tool can validate the mapping between someServiceName and someServiceUser
to be according to the requirements. This can be specifically useful in
upgrades you will have a way to see it the repo has what it needs for the new
code to work properly.
Marius
On 12/7/15, 3:22 PM, "Bertrand Delacretaz" <[email protected]> wrote:
>Hi,
>
>On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler <[email protected]>
>wrote:
>> ...do we have a solution now on how to
>> define the service user and ACLs in the provisioning model?...
>
>I'm hoping to find time to work on this soon, for now I had a look at
>the ideas in JCRVLT-61 and chatted with Robert and we came up with the
>following suggestions for two simple mini-languages that we can use in
>our provisioning model:
>
>a) Creating service users (this one is definitely a micro-language ;-)
>
> # comments and blank lines are supported of course
> create service user printService,someService
> delete service user printService,anotherService
>
>b) Setting ACLS from our provisioning model:
>
> # comments and blank lines are supported of course
> set ACL on /libs,/apps with glob */install/*
> remove * for user1,user2
> allow jcr:read for user1,user2
>
> deny jcr:write for user2
> deny jcr:lockManagement for user1
> end
>
>Both mini-languages should be implemented in their own modules so as
>to be reusable in other contexts, automated tests for example, and
>maybe JCRVLT-61 if the Oak folks are interested.
>
>I have created https://issues.apache.org/jira/browse/SLING-5355 for
>this, if someone needs it and can help feel free to jump in!
>
>-Bertrand
