Meta files for files without new interfaces
Niels Möller wrote:
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
On Sat, Jan 19, 2002 at 11:35:46AM -0800, Justin Langer wrote:
What can be its possible application?
You could access the web with all tools, including your shell. Instead
running wget, you could just try to use cp, for example.
This httpfs discussion made me think some more about one of my
wouldn't-it-be-nice-to-have wishes for the Hurd. Sorry to bore you
with it again, but I can't help myself. ;-) You have been warned...
I want property lists on inodes. Even if it isn't supported at all by
major filesystems like ext2, it would still be very good to have a
standard interface to properties for filesystems where it makes sense.
Some obvious applications:
Adding properties is a simple matter of adding a few more rpc calls to
the file interface.
What would be even cooler is to be able to provide a list of
properties when *opening* a file. The filesystem would then find data
matching the properties. For instance, the httpfs translator could put
such properties into forms variables and/or cookies. A versioning
filesystem could recognize a version number-property. A cvs filesystem
could recognize a branch tag property.
As a way to avoid new interfaces for dealing with properties, we can use
the empty file name "". So `cat index.html//mime/content-type' would
print `text/html'. There can be a convention after the two slashes to
reside a package name and after that whatever metainfo has the package.
This way it is possible to preserve metainfo when backuping to a
simple media and restoring the files will restore the metainfo as it was
in the translator! (There are many details, of course.) Touching `cp'
and similar commands to support this will cost little.
Actually this metainfo will turn to virtual directory of files and
directories that can be touched with `bash', for example. This
metadirectory can be used to control translators, not only to query
them. To avoid conflicts it would be best to reserve the first level for
package names. (I mean Debian package, but the idea can be generalized.)
Ognyan Kulev <firstname.lastname@example.org>, "\"Programmer\""