> From: Hans Reiser <[EMAIL PROTECTED]>
> Jens Benecke wrote:
> >User space: There should be a way of specifying what default MIME type a
> >file should get and whether the MIME type should follow the extension (if
> >it has one). One thing I didn't like in OS/2 was that sometimes it was
> >really difficult to persuade the WPS to open a specific file with another
> >viewer by default (eg. hex viewer). Changing the extension didn't help and
> >the EAs weren't editable without extra tools.
> >
> I think this is the most important thing, that one should be able to
> cast a file into a different type. Then one also needs to be able to
> convince app writers to try to make their apps work on the most generic
> type possible, which is difficult to do but probably we will have to
> endure failure at this in return for the benefits of typing and the
> object orientation it allows.
>
> I think that at this point we just need to focus on completing version
> 4, and it is good to know that people will use its features once they
> are available. We are indeed going to give you the flexibility you need
> to create whatever file/attributes or file/forks you need, though we
> will make do this by making files and directories able to do what you
> want attributes and resource forks able to do (this is nontrivial).
Yes, once everybody supports it, it will no longer be an issue, however
what should you get when you open the various resources? You need to be
able to get *everything* for programs such as tar and cp, but then you've
got ordinary programs that just want their data. My tendancy is that the
prior suggestion of the structured file is the way to go. Open "file" and
you get *everything*, open "file/data" and you get only the data.
> ..content-type turns out to be something that needs no specific support
> in version 4, the generic mechanisms will be enough for it. Suggestions
> for alternatives to .. as the style convention for meta-data about an
> object are welcome.
May I suggest "//" instead? This is much better for a couple reasons.
First "/" by itself is already a magic character, and so this doesn't
annoy people by stopping them from creating files with certain names;
same for programs. Second this is usable on directories, ie a file "bar"
inside a directory "foo" ("foo/bar") is distinct from an attribute "bar"
on the directory ("foo//bar").
There is an issue of going completly overboard,
"attribute/subattribute/subsubattribute" anybody? This is certainly an
overall interesting idea. How about "file//acl" for accessing ACLs? This
does mean though you *MUST* have a filesystem specific dump tool.
--
|\__/|\__/|\______ --=> 8-) EHM <=-- ______/|\__/|\__/|
\ | | | [EMAIL PROTECTED] PGP 8881EF59 | | | /
\ \ | ______| -O #include <stddisclaimer.h> O- |______ | / /
\___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
