For what it's worth, my list of semantics for EAs/forks (NOT structured
storage. *please* note the difference):
- EAs can vanish. Anything using them must expect this to happen.
- EAs are not heirachical - a file can have EAs associated with it, but an
EA cannot have more EAs associated with that.
- Files with associated EAs look like files. stat() should return a
S_COMPLEX, or something, but to the user, a file is still a file.
- Being able to access EAs using a specific naming techinque (such as
file/EA-name, or file:EA-name) would be useful (and probably the most
sensible way of going about things)
- A file+EAs is not a directory. Ideally, opendir(file) would fail, as it
does now (and an additional call to open the file for enumerating the
EAs should be added, although there's no reason why it couldn't return
a DIR * instead of some redudant new type)
- EAs can be useful, even where the OS wasn't built from the ground up to
support them (because of their 'optional' nature).
- Access permissions of EAs could either inherit totally from the file
associated with them. Alternatively, one could specify an alternative
(slightly more complex) way of doing it:
* You cannot write to an EA unless you can write to the associated file.
* You can read an EA if you can read the directory containing the file.
(So you can get the icon for a file, even if you can't actually get
the file itself - neater from a user perspective).
* You cannot remove/rename an EA unless you can write to the associated
file.
* You cannot list EAs unless you can read the file (not sure about the
point of this one, but it seems logical).
Everyone else can decide on whether EAs could ever be
executable. Although I could see the merit of attaching a special
wrapper shell-script around a program, and storing it as an EA
associated with the program's executable, I'm not sure it wouldn't just
complicate matters horribly (and confuse users).
On the other hand, for structured storage:
- A file is a directory is a file. The difference is the attribute and how
that makes things appear to the user. The whole thing is heirachical,
though (i.e., sub-files have the same semantics as files).
- Nothing's expected to have to cope with sub-files vanishing at random
(no more than they're expected to cope with a user doing 'rm
directory/file' these days)
- EAs could be implemented as a sub-file using structured storage, but not
the other way around - and even if they were, this is an implementation
detail that should *never* be relied on.
- Structured storage looses usefulness on an OS not built for it (Anybody
remember Microsoft's plans for Cairo, aka Windows 2000, and the Object
Filesystem they were going to implement?), because applications taking
advantage of it loose portability. Wheras EAs can be enabled/disabled at
compile time without massive losses in functionality, the the same
doesn't really apply to SS, where if you're going to use it, you go
the whole hog or not at all.
I'll shut up now. :)
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:28 EST