[OpenAFS-devel] Java API for AFS Admin -- CORRECTION!

[Ted Anderson]

On Tue, 19 Mar 2002 14:09:28 -0800 "Leo Luan" <luan@almaden.ibm.com> wrote:
> The problem with getCreator returning a User object is that a Group
> could actually be the creator (e.g. system:administrators is the
> creator of system:administrators), and Java doesn't support covariant
> types.  The underlying native library refers to the creator by name
> and id, and we found this useful; and the user of the API could
> determine whether it's a user or a group from the id and then
> construct the appropriate object with name if needed.

Derrick's suggestion to create a more primitive PtsEntry class to
underly both User and Group classes seems like a good one.  Perhaps this
approach would help with integrating other user authentication
environments such as MIT Kerberos and ActiveDirectory.  Though I agree
it will take more experience to enderstand how best to tackle this.

> We've taken all ACL-related methods out of the API.  We instead have
> them in another, more file-centric application we've developed.

Managing ACLs is often a part of the AFS administrator's job.  The
question is how important it is to modify ACLs from automation tools.  I
would think setting up user environments, for example, would often
involve setting ACLs.  Hopefully this other file-centric application
would not be too dissimilar from the AdminAPI so that Java code that
needs capabilities of both types can easily access them.

> We haven't experimented with salvage too much; is the output useful
> enough to provide this as a feature?  If so, it would probably be
> pretty easy to do through getLog as you suggest; we'd just like to
> hear some arguments in its favor.

I'm not experienced in this area.  Salvage does have verbose diagnostic
output that can be useful for debugging.  Also there is the -showmount
option, which returns a list of mountpoints in a volume.  Though perhaps
neither of these needs to be built into the Java API.

> Yes, multiple IPs will be supported in the next version of the API.  The
> string representation the IP addresses is just a normal Java String -- it
> can represent anything it needs to. Do you think any special considerations
> need to be made for IPv6?  It is dotted quad, there will be an example in
> the next version.

I really don't know enough about IPv6 to answer this question.  In any
case, I suppose that is farther off then many of these other issues.

> We're actually thinking about our caching mechanisms in a very
> different way: we want them to be as simple and out of the way as
> possible, and let the application take care of when it wants the cache
> refreshed, etc.

I'm all for this, but I worry that simple, hidden and flexible, may be
hard to achieve simultaneously.

> As far as adding callbacks, this would probably require changes to AFS
> itself, which is not our intention.  We're not completely aware of
> what callbacks AFS currently supports, but these features are not
> supported in the administrative library we've built this API on, and
> we think it would make things a bit more complicated than they need to
> be.

AFS callbacks are issued for modifications to files (and releases of R/O
volumes).  So changes to attributes that the AdminAPI might cache would
require new mechanism.  In some cases it would certainly be handy, but I
don't know if the utilization of the AdminAPI would be intense enough to
justify such effort.  It is something to keep in mind, but probably
not worth pursuing now.

Ted