directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Fwd: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Date Wed, 02 May 2007 16:38:23 GMT
Alex,

Bringing this mail again to your attention. Please let me know is
there is any pb.

---------- Forwarded message ----------
From: Ersin Er <ersin.er@gmail.com>
Date: Apr 6, 2007 7:50 PM
Subject: [ApacheDS][Core] About the "extended" subtree specifications
w.r.t. several ACI components
To: Apache Directory Developers List <dev@directory.apache.org>


Hi all,

As PAM and Stefan are close to finishing the ACI editor, they have
asked me a few questions about the "extended" subtree specification I
introduced in 1.5. Although I have explained these changes on JIRA and
IRC, I wanted to record them here on the list also.

What we did in 1.5 branch about Subentries and subtreeSpecifications
in particular is allowing regular LDAP filters to be used in the
specification instead of refinements. Refinements can only be used to
specify boolean combinations of object classes. However it is obvious
that in this new "flat" directory world, people would like to "select"
portions of the DIT via any entry attributes as well as objectClass.
So people would like to be able to specify a set of entries to protect
via ACIs not only saying "those persons (according to objectClass
attribute)" but also saying "those persons who are from X department
(according to some user attribute)". This is what we provided.

So, now, regarding to subtreeSpecification related components in ACIs.
They have not been effected by this change because they cannot be and
we did not want also. There are two components that may come to mind
about this change. First is the "classes" protected item and the
second one is "subtree" user class. The "classes" protected item has
the refinement syntax and it is really used for specifying a boolean
combination of object classes. It can never include regular attributes
other than object class values. So it does not have to support the
LDAP filter syntax. The "subtree" user class, although it has
subtreeSpecification syntax (particularly), it does not even support
refinements; so there is nothing to be replaced with ldap filters.

I hope it's clear.

--
Ersin


-- 
Ersin

Mime
View raw message