Re: svn commit: r11750 - branches/locking/subversion/include

[email protected] 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