You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2005/09/15 18:30:47 UTC
[ApacheDS] [ACIItem] grantsAndDenials: bit-list verses bstring
Hi all,
I thought I'd break this out into a separate thread and we can discuss
this issue in isolation.
User Centric (Intuitive) Representations
=======================================
I just talked to Ersin on IM. He clarified the differences between
using a bit-list and a bstring. If we use a bstring then the user would
have to enter long 25 + 1 (for B) character strings like
'0100010111101010110111010B' to represent the various grants and denials
(perms) associated with the ACIItem. The user would have to keep in
mind the permission associated with every index. This would be really
hard and not so user friendly. Keep in mind the way people will use
this. They will perform modify operations where they add an aciItem
attribute to an entry with the aciItem string. We cannot expect them to
use this binary string representation.
A bit-list is a list of identifiers where order does not matter. The
identifiers in this case are the names of the permissions. Here's an
example that Ersin gave me online:
grantsAndDenials { grantBrowse, denyModify }
Now this is much more intuitive to human users than the following
bstring representation for the same set of permissions in the bit-list
above:
'0000000001000000010000000B'
I think it's a no brainer regarding what we want for the String
representation of the ACIItem.
Runtime Machine Centric Representations
=========================================
Now is this representation the best for the machine? Probably not.
Trustin will most likely prefer a BitSet or even a primitive int where
the bits in the int are toggled to include the permission. I don't know
which he will prefer and we'll leave it up to him.
However the human representation communicates this structure. The user
can later modify this attribute to add or remove more permissions from
the list. The parser takes this and converts it into the runtime
representation by populating Trustin's beans for ACIItem and its elements.
Alex
Re: [ApacheDS] [ACIItem] [User Centric (Intuitive) Representations]
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Alex,
> You're still thinking on the programmatic level.
eh eh, yes. My bad ;)
<snip/>
> Well sure this is the same outcome I was hoping for :). It gives us a
> simple easy to use textual representation for the user.
+1, even if it takes me some time to reach this conclusion.
Emmanuel
Re: [ApacheDS] [ACIItem] [User Centric (Intuitive) Representations]
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
Re: [ApacheDS] [ACIItem] [User Centric (Intuitive) Representations]
Posted by Emmanuel Lecharny <el...@apache.org>.
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 )
- 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.
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
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?
Re: [ApacheDS] [ACIItem] grantsAndDenials: bit-list verses bstring
Posted by Trustin Lee <tr...@gmail.com>.
What do you think about Java 5 enums? I guess it will resolve most issues
IMHO.
Trustin
2005/9/16, Alex Karasulu <ao...@bellsouth.net>:
>
> Hi all,
>
>
> I thought I'd break this out into a separate thread and we can discuss
> this issue in isolation.
>
>
> User Centric (Intuitive) Representations
> =======================================
>
>
> I just talked to Ersin on IM. He clarified the differences between
> using a bit-list and a bstring. If we use a bstring then the user would
> have to enter long 25 + 1 (for B) character strings like
> '0100010111101010110111010B' to represent the various grants and denials
> (perms) associated with the ACIItem. The user would have to keep in
> mind the permission associated with every index. This would be really
> hard and not so user friendly. Keep in mind the way people will use
> this. They will perform modify operations where they add an aciItem
> attribute to an entry with the aciItem string. We cannot expect them to
> use this binary string representation.
>
>
> A bit-list is a list of identifiers where order does not matter. The
> identifiers in this case are the names of the permissions. Here's an
> example that Ersin gave me online:
>
>
> grantsAndDenials { grantBrowse, denyModify }
>
>
> Now this is much more intuitive to human users than the following
> bstring representation for the same set of permissions in the bit-list
> above:
>
>
> '0000000001000000010000000B'
>
>
> I think it's a no brainer regarding what we want for the String
> representation of the ACIItem.
>
>
> Runtime Machine Centric Representations
> =========================================
>
>
> Now is this representation the best for the machine? Probably not.
> Trustin will most likely prefer a BitSet or even a primitive int where
> the bits in the int are toggled to include the permission. I don't know
> which he will prefer and we'll leave it up to him.
>
>
> However the human representation communicates this structure. The user
> can later modify this attribute to add or remove more permissions from
> the list. The parser takes this and converts it into the runtime
> representation by populating Trustin's beans for ACIItem and its elements.
>
> Alex
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/