sussman@tigris.org wrote:
>+/**
>+ * ### Note: this paves the way for future ACL stuff; someday a user
>+ * object can contain information about group membership, and so on.
>+ * Because it's an opaque type, we can easily add new fields and
>+ * create new accessor and setter functions.
>+ */
>
>
I'd like to clarify this "ACL stuff". Because we must model our ACLs to
be compatible with the DAV ACL spec, we need an easy way to ask if the
current FS user belongs to a particular group (because an ACL entry
might refer to a group, not the user explicitly). The FS doesn't care
where those group membership mappings come from, so as far as its
concerned, a list of groups would suffice.
However, there are lots of ways to map a username to a group; various
PAM mechanisms on Unix, Apache's auth methods, Windows user info, DAV
principal trees, etc. etc. Because of that it is quite reasonable that
we can't simply add a list of groups to this struct, but rather a
callback function that can answer the question, "is this user in that
group?".
Of course, none of this means there's anything wrong with the opaque
struct approach. I just want to point out that this simple struct may
well become a lot more complex later on.
Ah yes, it might be a good idea to note in the docstring that the
lifetime of svn_fs_user_t objects must be the same or longer than the FS
object's lifetime.
>+svn_error_t *svn_fs_lock (svn_fs_lock_token_t **token,
>+ svn_fs_t *fs,
>+ const char *path,
>+ svn_boolean_t force,
>+ long int timeout,
>
>
Is there any reason why this can't be apr_interval_time_t?
-- 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 02:07:48 2004