[OpenAFS-devel] DRAFT: New sysname standard

[Derek Atkins]

I agree that we would need conventions for @-variables.  That doesn't
make the proposal un-worthwhile.  It just means that the proposal
isn't yet complete.

Perhaps we should add to the proposal a set of well-defined (by
convention) variables that can have some pre-defined defaults.  Host
administrators can then change those defaults, of course, but they
would at least exist in some native form.

If we had enough of these @-variables, hopefully nobody would really
see the need to make their own extra ones, even if the interface
existed.

-derek

Ted McCabe <ted@MIT.EDU> writes:

> At 1:29 PM -0400 5/8/01, Derek Atkins wrote:
> >This is already an issue today.  There are sites that use their own
> >@sys values.  I've seen, for instance, i386_rh60.  They just need to
> 
> Yes, it is an issue today.  As I understand it, this example is due 
> to the current set of possible @sys values not being sufficiently 
> specific in definition nor broad enough in scope.  Thus the new 
> proposed standard.
> 
> >have their workstation startup scripts run "fs sysname i386_rh60" and
> >voila, they have a new, "non-standard" sysname.  Adding new sysnames
> >do not, IMHO, make the problem any worse than it is today.
> 
> I agree, adding new sysnames, or using unconventional sysnames 
> doesn't make the problem any worse.  Adding arbitrary new @variables, 
> which is the suggestion I was responding to, does make things worse.
> 
> Also:
> At 1:19 PM -0400 5/8/01, Jim Rees wrote:
> >   Such a scheme for allowing dynamic allocation of additional/arbitrary
> >   @variables seems to require a method of exporting your @variables and
> >   mappings so that other cells can understand your filesystem.
> >
> >What do you mean by this?
> 
> First off, small correction.  After some more thought, I would change 
> the word "cells" to "clients".  To elaborate further:
> 
> We are quickly approaching (if not already in) an environment whereby 
> a significant number of AFS users administer their own machines.  The 
> proposal that I am replying to would allow those users to define, and 
> then use in their own part of the filespace, arbitrary @variables 
> with arbitrary values.  Looked at from the POV of a systems 
> administrator who wants easy, full control over my machines, this 
> seems like a wonderful thing.
> 
> However, when I look at it from the POV of someone who considers how 
> easy this might be for users to cope with, one thing jumps out at me 
> as a big pain in the butt.  There is, a priori, *nothing* that gives 
> me any clue how to interpret, for example @machine, were I to 
> encounter it in a path and my particular client were not already 
> aware of some interpretation thereof.
> 
> Granted the problem exists now with possible use of non-standard 
> values for @sys, but that's still a much simpler and smaller 
> translation problem.  The feature of arbitrary @variables seems to be 
> very likely to make this translation problem extremely more 
> difficult.  More difficult that is, unless we also provide a means 
> for clients to somehow readily be made aware of another client's 
> @variable mappings.
> 
> Right now at least the @sys interpretation, tho' technically free to 
> be arbitrarily defined from client to client, is well-defined by 
> convention.
> 
> >   Otherwise, there's nothing standard about it.
> >
> >Variable names and values would be standarized by convention only, just as
> >they are today.
> 
> Yes, but at least we have a convention.  The proposal I am objecting 
> to lacks any such convention.  I can imagine such a convention coming 
> into being for specified @variables (which reminds of other issues, 
> but issues that I see as eventually resolvable and not germane here). 
> With arbitrary @variables coming into play, I can only imagine 
> confusion as the result.  I'd welcome any method of establishing an 
> @variable/value convention that could avoid said confusion while 
> supporting arbitrary @variable usage.
> 
>     --Ted
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available