On Fri, 2004-11-05 at 08:10, Branko Èibej wrote:
> I'm really getting a bit tired of this. With or without an ACL design
> doc, we know that in order to be compatible with the DAV ACL spec, we'll
> need at least information about the user's group membership.
I'll take your word on that. But there are other ways of doing that
besides inventing a "user" concept which can be queried for membership
in a group. Maybe the group database will be managed inside the FS.
Maybe the FS could be passed a list of groups for the user. Maybe there
will be other things besides username and group membership that we want
a callback for, such that "user" is a poor name for the opaque object we
want. (I already think it's a little bizarre to query a "user" object
for whether it's a member of a group. If you want to know whether a
user is a member of a group, I'd say you should ask the group, or ask
some object which contains a group database.)
My point is, we're solving locks. Locks are a simple problem. ACLs are
a really hard problem. (You may think you have a solution for them in
your head, but I'm about 90% confident you've glossed over some
tremendously importand detail. Since you won't write down your
solution, it's hard for me to justify that.) Making a random stab into
ACL territory is a mistake, in my opinion, unless we can justify that
there is a large cost in not doing so. Updating one or two APIs is not
a large cost.
> Knowing
> that, but not knowing other details, designing an API that's extensible
> seems eminently sensible. Calling an opaque struct vs. a const char*
> "overengineered" is just a bit over the line, IMNSHO.
In my opinion, the surface complexity of an API increases dramatically
as you create new types. If we create a type and later decide not to
use it, that's much more confusing than updating the signature of one or
two functions.
> Besides, updating APIs that could have been designed correctly in the
> first place is a royal PITA.
Not true. If you turn out to be right all along, we create the user
type, add svn_fs_set_user(), and change the deprecated
svn_fs_set_username() to create a user object with no group information
and set that.
> So, -1 on changing the user info stuff.
You overuse your veto. Stomping your foot and insisting that the
locking system must solve 2% of an ACL design you won't write down is
inappropriate.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 16:36:32 2004