file attributes

[Erik M. van der Poel]

Boyd Roberts writes:
> `human readable'?  So what language are you going to choose?

I covered this in my comp.std.internat article:

	Message-ID: <1719 at sranha.sra.co.jp>

If there is enough interest I could re-post it, or I could email it.


Martin C. Atkins writes:
> Managing the namespace, and standardizing the properties that
> are stored with files is a nightmare!

Well, it certainly isn't trivial to decide upon and register
attributes, but some of this is already in place in ISO. Again, the
above-mentioned article of mine already covers this. (I realize that
the current discussion about X.400 and object management in
comp.std.unix may have a lot to do with this. But are they also
considering human-readability and all media? This is not intended to
be a rhetorical question.)


> 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).


> 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.


> 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.


> 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?


> 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.


Sean Eric Fagan writes:
> 2.  A *much* better way to do what you are trying to do, that *has* been
> done before, that is much more general, elegant, etc., is to use watchdogs.

What I'm trying to get systems vendors to do has not been done yet.
Cartridges are not being written with standard headers containing
internationally registered attribute names and values.

Thanks for the reminder about watchdogs. I just read a paper on
watchdogs starting on page 267 of the Winter 1988 Usenix proceedings.
Very interesting, actually, coz it makes good use of a couple of ideas
that I'm also trying to use. Namely, (1) that it is transparent, and
(2) that it does not allow circumvention by the user, because it is
implemented at the system call level. I.e. the user calls open(),
close(), read(), write(), etc, but does not realize that a watchdog
might actually be controlling all of those operations.

So let's suppose (just for the moment) that we are using watchdogs,
and we want to implement a GUI that allows applications to be invoked
by double clicking on the file's icon. (Remember: we're talking about
the user's *preferred* application for that file. If the user wants
the GUI to run `od' on files of type `Oracle', sobeit.) Since the
open() is supposed to be transparent, the application does not see the
metadata, right? Or do we need to update all applications? Assuming
the former, how does the GUI itself access the metadata? A new system
call? Or is the GUI itself a watchdog? There are various possibilities
here. What did you have in mind, Sean?


> Wait... let me get this straight:  system software never needs to see it,
> only user software.  So we have to add a system call.

***IF*** we have a system call, mopen(), that accesses metadata, and
open() accesses the data itself, ***AND*** we put email-like metadata
headers in front of the data in a cartridge, then the system only
needs to separate the metadata from the data. It does not need to
recognize the name-value pairs themselves, since it only needs to find
the end of the headers.

By the way, watchdogs require another system call (wdlink()).

Another by the way: Have watchdogs been added to POSIX yet?


Joshua Osborne writes:
> 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?

If you separate the metadata and data on disk, you don't need to sift
through the metadata after open(). You need to parse headers in
cartridges, etc, but this is not very slow compared to the
tape-reading itself, particularly if you pad the metadata to the block
size.


> We get a new spec: hashed meta-data, new sys-calls, and ...

Nope, we don't need to change the specs.


> Then what happens when people decide that some meta-data is a per-user
> toy ...

This has been covered in this newsgroup before.


> What happens when I want some meta-data to chain off of environment
> variables?  (secondary action for Makefile is the value of PAGER...)?

This would be a user level change. The system call level spec is
unchanged.


> Would it be better if Sun had made SunView (or SunTools?) the
> "standard" before they learned that NeWS was way better?

It seems to me that NeWS is far more complex than the simple system
call that I am proposing. Apples and oranges.


> A new shell syntax (grep "FOO=.*BAZ.*BAR" <# foo)?

Yes, there may be some way to extend the shell syntax.


Rahul Dhesi writes:
> Frankly, I *don't* think UNIX users should revert back to the Dark
> Ages, when there was One Standard Thing they could do quickly with any
> file, and everything else took multiple menus and multiple mouse
> clicks.

I'm not trying to get Unix users to revert to the Dark Ages. I'm
trying to allow non-Unix users to use Unix (easily).
-
-- 
EvdP