file attributes

[Joshua Osborne]

In article <1792 at sranha.sra.co.jp> erik at srava.sra.co.jp (Erik M. van der Poel) writes:
>> Where there is no implementation there should never be a standard.
>
>I agree that, in some cases, it is highly desirable to implement
>prototypes before attempting to put specs in a draft standard. In
>particular, if it's very complex, one should implement it first to
>prove that it's feasible.
>
>It seems to me, however, that this is not the case with my metadata
>proposal. It is extremely simple, and any IT professional should be
>able to see that it is implementable. One possible syntax is a number
>of lines (Name: value) followed by an empty line. This is both simple
>and extensible. Don't forget that the *system* software does not need
>to recognize the names and values. Only user software does. (Access
>control lists were mentioned by someone else, not me. We probably want
>to put ACLs in an extended inode, under the control of the system for
>security purposes.)

So what happens after some POSIX-meta-data compliant systems come out,
we attach great huge festering gobs of meta-data to our files, then
can't process the meta-data fast 'nuf because we can't sift through the
keys quickly?

We get a new spec: hashed meta-data, new sys-calls, and an obsolete spec that
needs to be implemented by everyone (rather then just one vender for a few
years), and may never die out (newbie programmers will use it, people may
never port old programs to the hashed way since the "old way" will be
around forever (it's POSIX standard now)).

Then what happens when people decide that some meta-data is a per-user toy
and other a per-group, and others a plain item (the default action for
Makefiles for me is make, secondary is vi; other people may want them to
be pmake & emacs for the same file).

New spec: user dependent meta-data.  2 old formats to support until the
end of time.

What happens when I want some meta-data to chain off of environment variables?
(secondary action for Makefile is the value of PAGER...)?  New spec, 3 old
ones to support 'till Sol goes nova.

What happens when I want meta-data to be hot-linked from one file's m-d to
another?  New spec: 4 to support, one to use...

(What if I want fast wild card support, or somthing like X's resources?)

>Also, in the case of this metadata proposal, it does not make sense
>for only a small number of organizations to implement it. A large
>number of implementations should exist if it is to be truly useful and
>simple for the end-user. Again, migration is covered in my
>comp.std.internat article.

Do it once, fall on your face.  Do it again, learn to walk.  Do it again,
learn to run.  Do it again, fly.  Don't make us all fall down with you.
Invite us to fly.

>Finally, this implement-before-standard approach needs to be used with
>considerable care. In the past, many hardware and software
>implementors did their own thing, without regard for the end-user, who
>must live in a world of heterogeneous systems, and would like to
>exchange data with peers. We need industry-wide de facto and de jure
>standards that don't obstruct innovation.

Would it be better if Sun had made SunView (or SunTools?) the "standard" before
they learned that NeWS was way better?  (never mind that we chose X, or even
if X is better; I don't know much about NeWS, I know lots about X; I like X.
NeWS may or may not be better.  This is the wrong place to argue.)

If so you wouldn't have a networked window system.  You would have (if you
are lucky) a network kludge (I don't think SunView would work well over a
network).

What about Network File Systems?  I may not like NFS, AFS may be better, or
RFS for all I care.  All 3 beat the hell out of ND.  That's what we would have
if we "standardize first", then test.

>> If enough vendors see the value of a feature
>> or (equivalently) believe that the market demands that feature, that
>> feature becomes a de facto standard.
>
>Exactly. I am currently trying to get the vendors to see the value of
>this extension.

Fine.  Make it work then make them believe.  Hell, make it work then make it
POSIX.

># Anyway, making vendors "feel obliged to support it" because of a standard
># is a sure sign you've done a bad job.
>
>I agree with this, actually. I shouldn't have said it the way I did.

Then we don't understand what you want.  Just a design, then a standard?
Or a design, an implmentation, a (at least) few months use, then a standard?
Go the RFC route?  Lots of good "standards" started that way.

>: But what scares me about environment variables for files is the
>: prospect of the day I see a user type:
>: 
>: 	grep foo < 'LRECL=80,RECFM=V,DISP=(OLD,KEEP,DELETE),DSN=data'
>
>If metadata is added to Unix files, we will grep this way:
>
>	grep foo data

How do we grep for a meta-value ("any files that set the FOO variable" or
"any files that set FOO to GOO" or "any files that set anything to GOO" or...).

How do we use the power of the standard (and non-standard) Unix tools on
meta-data?  A new shell syntax (grep "FOO=.*BAZ.*BAR" <# foo)?  New
versions of all the standard (and non-standard, mperl...) programs?


[[Please don't think this message endorses meta-data support from the kernel,
I think it belongs outside; but I am willing to change my mind, bring me a
working version, I've got an open mind...     'till then I think it belongs
in another file, or all in one huge database, or...]]
-- 
           stripes at eng.umd.edu          "Security for Unix is like
      Josh_Osborne at Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"CNN is the only nuclear capable news network..."
    - lbruck at eng.umd.edu (Lewis Bruck)