Greg Hudson wrote:
>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.)
>
>
Did you read my other post,
http://svn.haxx.se/dev/archive-2004-11/0246.shtml?
Certainly, the name "svn_fs_user_t" isn't optimal. I'm thinking along
the lines of an authentication token, so "svn_fs_auth_t" might be a
better name.
>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.
>
Almost certainly. The need for a flexible way to pass auth info to the
FS isn't one of them.
> Since you won't write down your
>solution, it's hard for me to justify that.)
>
I object strongly to the "won't" here. You say yourself a few lines
before that ACLs are a hard problem. I'm working on that draft spec. Now
if I had unlimited time for Subversion, I would've posted it already.
Unfortunately I don't. But I won't use that excuse to publish a
half-baked design. I'm getting there.
> 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.
>
>
My point is that this particular discussion isn't about solving locking
or solving ACLs, but about presenting auhentication information to the
FS. This just happens to be a capability that both ACLs and locks need,
but it's a separate feature.
I find your talking about "random stabs" into this or that, as if I'm
pulling ideas out of the blue, just a bit unfair.
>> 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.
>
>
So, a new type whose full potential isn't realised when it's furst
introduced is more confusing than a bunch of deprecated functions that
will probably live in our API for years?
I think a new type adds about the same amount of complexity as a new
function. In fact, in the case we're discussing, you can do away with
the type completely, hiding it in the FS object, and simply pile on
accessor functions, and you'll get the same result, feature-wise. But
the API would become _more_ complex to use, because there'd be no
obvious mapping between features and function groups (except by function
name, which is not the best way). It's a lot better to have a set of
functions that all operate on the same (opaque) type, because then it's
obvious that the type represents a feature.
We already use batons for data abstraction and vtables for virtual
dispatch elsewhere, so I don't understand why OO design would be wrong
in this case.
>>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.
>
>
And we have yet another deprecated API to support until 2.0, where we
could've done it right the first time. Of which we already have a ton,
most of which could probably have been avoided if we'd used a more
extensible API design. I don't want us to repeat the same mistake.
>>So, -1 on changing the user info stuff.
>>
>>
>You overuse your veto.
>
I don't think so. I have given valid techical reasons for it.
> Stomping your foot and insisting that the
>locking system must solve 2% of an ACL design you won't write down is
>inappropriate.
>
>
It's not about the locking system solving the ACL design I "won't" --
there it is again -- write down. It's about abstracting authentication info.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 22:15:08 2004