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
Enum.
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.
Alex
