[AFS3-std] Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Jeffrey Hutzelman]

On Tue, 20 Feb 2007, Matt Benjamin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey Hutzelman wrote:
>
> > I don't recall the conversation specifically, but there certainly is an
> > established consensus that we should be adding get-capabilities ops to
> > each interface.  Such an interface would return a bitmask of supported
> > capabilities, similar to the ones we already have in some of the RPC
> > interfaces.  Forgive me for not going back and looking at your patch to
> > see if this is what you ended up defining.
>
> What Marcus and I defined is, apparently, not a capabilities interface.
>  Rather, it is a properties interface.  Rather than a bitmask, our
> implementation is a dynamic string table.  The 'get' interface takes a
> key, which may include wildcards, and may return values for multiple
> keys.  In our code that uses this interface, we created the convention
> of defining keys of the form <subsystem name>.<keyname>, so we have
> 'rxk5.enctypes'.  Although we did not initially implement a
> corresponding set interface, we have been thinking that it could be
> useful to have one, although we haven't (at least together) thought out
> all the implications (ie, per-user vs. system-wide properties).  This
> sort of interface would, I think, reduce the need for new get/set pioctl
> interfaces for this that and the other.

Hm, right; I think one of you described this before, and I just forgot.
As I warned, I didn't actually look at the code while I was writing that
message.  I don't have any fundamental objections to this approach, though
I'm a little nervous about wildcard-matching code and would want the
actual implementation to be carefully reviewed by someone who didn't write
it.  Of course, lots of our code could use some auditing; anyone who feels
they have time to do so is welcome to speak up.

There are a number of dimensions to think about here.  Obviously a set
operation brings up the question of which properties are read/write vs
read-only; in fact, there may be some properties which are writable only
by root and others which can be written by any user.

Per-user (presumably, per-pag) properties are an interesting idea, but
unless we have an immediate need, I think it might be better to defer it
for now.  If necessary, we can always define a new interface for per-user
properties at some point in the future.

There is also a question of namespace, and coordinated vs implementation
specific names.  Naming conventions such as you describe make it easier to
avoid collisions and to delegate (temporarily or otherwise) the authority
to assign some set of names.  But there is still a need for a canonical
list of properties and what they mean, for interoperability's sake.


> We did not consider enctypes to be capability bits (see above), but
> rather, we used an ascii representation of the integer number
> corresponding to the enctype in the k5 specification.

Hm.  Are all property values strings?  I sense a charset question that
should be resolved early on.


-- Jeff