directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] [ACIItem] [User Centric (Intuitive) Representations]
Date Fri, 16 Sep 2005 14:59:52 GMT
Emmanuel Lecharny wrote:

>Hi all,
>here is some though about representation of grants :
>we don't care. 
>Let me explain why I'm so brutal ;) :
>- this is something that will be hidden from user face. ( at least as
>soon as we have a cool GUI to deal with those grants )
You cannot always expect to have a GUI around.  First off we don't have 
a nice GUI tool for this and secondly even if we had one I'd probably 
not use it for the day to day.  Half of the UNIX world would probably 
prefer to use command line tools to add ACIs anyway.

For example I don't mess around with JXPlorer.  I just use the command 
line tools to test fuctionality.  Why?  Well many reasons.  I don't 
trust GUIs.  I think command line stuff is simple and to the point.  I 
don't have to use my mouse etc. 

UIs do help some people.  However in my experience no serious UNIX admin 
ever messed around with UI tools to do his/her job.

>- and as soon as it works, it's ok. Even if it's complicated to
>understand, we will always be able to have a clear view of grants if we
>use - as suggested by Trustin - jdk 1.5 enums.
You're still thinking on the programmatic level.

>So the questions are 
>- how do we translate those bits to an internal representation
>- what is the easiest way to implements those ACIItems
>- what are the performance impacts on the whole system of this encoding
>and translation

Ok let's stop for a sec.  Look the perscriptiveACI (in subentries) and 
entryACI (in entries) attributes will store one or more ACIITems.    
Both are multivalued.   These are not controls, they are pain old 
operational attributes.  Think of these attributes and the ACIITem 
representation they hold as the human DSA interface.  The representation 
is not the internal representation. 

Internally the directory can represent an ACI in any way shape or form 
it wishes to do so.  This does not change the fact that some user is 
going to have to add or modify an ACIItem in an entry or a subentry.  
When they do so it should be as easy as possible to do.

You keep asking the price we pay in terms of performance for this 
representation.  Really it's not relavent here since the internal 
representation will not be the same.  We are not going to parse these 
ACIs at search time.  That would be ludicrous and would slow search down 
to halt.  I have tactics for making sure we do not tax search operations 
in mind.  I used similar tactics while implementing subentry support.

>I think that the third question is orders of magnitude less important
>than the two others.
>I buy the idea of having a clear text solution, like :
>"grantsAndDenials { grantBrowse, denyModify }", combined with Trustin's
>Am I right?
Well sure this is the same outcome I was hoping for :).  It gives us a 
simple easy to use textual representation for the user.  The Enum thing 
is for Trustin's data model which is for the internal representation.  
Ersin's parser basically transforms this user intuitive textual 
representation into Trustin's data model. 

BTW even Trustin has two representations.  One for ease of programatic 
handling.  And another representation based on ACI Tuples for the rapid 
computation of ACI rules in the ACDF.  Incidentally I intend to compute 
this representation and keep a hot copy hanging around to rapidly 
execute the ACDF.  I'm trying to determine what data structures would be 
best for doing this.


View raw message