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
