Greg Hudson wrote:
>>Maybe we don't need to have this abstract svn_fs_user_t thing that
>>brane proposed, though. We could simplify by just attaching a (const
>>char *)username to an fs_t, and leave it at that.
>>
>>
>
>That would be my preference. It would only require updating one API to
>change that to an opaque user object, should the need arise.
>
>(Updating APIs really isn't that painful. But if we overengineer
>something without thinking about it carefully and then find out that we
>went in the wrong direction, that's painful.)
>
>
Aargh!
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. 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.
Besides, updating APIs that could have been designed correctly in the
first place is a royal PITA. Sure there have been cases where we simply
didn't know about an APIs potential problems beforehand, and had to fix
it by adding an almost identical function. This isn't one of those cases.
So, -1 on changing the user info stuff.
-- 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 14:10:52 2004