file attributes

[martin at minster.york.ac.uk]

erik at srava.sra.co.jp (Erik M. van der Poel) responds to my message:
> Martin C. Atkins writes:
> > Managing the namespace, and standardizing the properties that
> > are stored with files is a nightmare!
> ...
> 
> > Centralized administration is out
> > of the question (no resources to support this,
> 
> It does not take up very many resources to map registered names to
> system-specific values. E.g. "FrameMaker" -> "/usr/bin/fm" (or
> whatever).

This is *not* what I meant! I meant good old-fasioned *human*
administration! This system was developed by a small organization
kept going mostly by voluntary effort. There is *no way* we could
have taken on the workload of maintaining the namespace without
charging (a disproportionate) fee to do it.

> 
> > it is too awkward for developers
> 
> Why is it awkward? Developers don't even have to think of their own
> attribute names. The central registration organization provides a
> list. And they can add new names.

As I said there *is no* central registration organization for the names
I am discussing. Anyway, if I understand your proposal corrently, what
is to stop two developers choosing to use the same name, which does not
appear on the current list, at the same time? To ensure uniqueness some
kind of coordinated registration/allocation procedure is needed. Also
developers must have some say over the names of attributes, so they can
make sure the name correctly reflects the meaning of the attribute they
are defining.  Otherwise we would end up with attributes such as
`EXXy55' meaning ``secondary application to invoke when double clicked
while meta shift left elbow is valid...'' :-)

Anyway this again wasn't what I meant! A central register of attributes
is `awkward' for developers because it means that when the developer
decides he wants a new attribute for something, he has to mail the
registrar, and wait for a reply before he can use it. This would mean
that many (well meaning) developers would simply allocate their own
attributes, for development and testing, while the bureaucracy gets done.
Some of these names are bound to get out by accident, or they might
forget to register some... are you proposing a new international crime -
promolgation of an unregistered file attribute?

Many of my end users are also developers, so whatever procedure is
adopted must be *very* convenient, and easy for them (they are generally
not computer scientists, and are likely to ignore instructions that
they don't see the point of, or don't contribute directly to the task
at hand - rightly so, in my view).

> 
> > and totally unenforceable)
> 
> Yes, well, this has always been the case. Well-intentioned
> organizations have been producing standards for years, and many
> vendors simply ignore the process. Look where that got us today.

Yes, and many well-intentioned organizations have been producing
PERFECTLY DREADFUL standards for years! Such standards deserve
to be ignored.

> 
> > Changes to allow directories to be moved and copied more
> > freely seem to be enough to make this a better solution than attaching
> > properties directly to the files.
> 
> Yes, this is another alternative. We need to leave the options open.
> But what do we do about tapes with metadata headers? Do we access the
> metadata through /dev/cartridge/metadata?

If you like - at least this doesn't involve cludging up the system!

> 
> > It also makes it much easier to avoid horrible restrictions/implementation
> > problems on the size (and the changes in size) of properties.
> 
> The email-like header syntax does not suffer these problems.

The email-like header has *exactly* the problem to which I'm refering.
Please show me how to change one of the header lines to a value longer
than the current value (or insert a new header line), WITHOUT having to
copy the rest of the file - remember the sound files I'm dealing with
are seldom less than 10 Mbytes in size, and are regularly ~100 Mbytes.

So what is the solution? We put the `headers' in another file, and
attach it in some way to the data - by putting them both in the same
directory, say. No new mechanisms are needed.

Martin