Re: Extended attributes

[Brian May <bam@debian.org>]

>>>>> "Pavel" == Pavel Roskin <pavel_roskin@geocities.com> writes:

    Pavel> GNU Hurd in not a single-user system!  There are several
    Pavel> serious objections against having system-wide extended
    Pavel> attributes:

With due respect, I think you have misunderstood the proposal (or
somebody here proposed something else).

    Pavel> 1) Different users may want to associate files with
    Pavel> different programs.  John may prefer to open *.html in
    Pavel> Lynx, whereas Maggy may prefer Mozilla.

The idea, I think, was to associate a file type with the file,
and not the application with the program.

eg Macintosh does it the wrong way, where a data file is associated
directly with an application (IIRC). 

Windows 98 is better (arrghh! did I really have to say that?), where a
file is given a file type, and an application is associated with the
file type. However, this file type is determined from the filename (ie
the extension), and restricts what filenames you may want to give a
file. Also, in order to change the file type, you must rename the file
and change any references to that file.

extended attributes (or whatever you call them) would move the file
type from the file extension, and into the filesystem.

Even better, would be to represent the files as mime types.  That way,
an association between mime types and applications already exists -
/etc/mailcap. This can be changed for individual users (~/.mailcap
IIRC).

Another benefit of mailcap - IIRC mailcap allows you to associate
multiple programs to one mime type, with the default being the first
one listed. I think a well written program would let the user select
which application he/she wanted to open the file with. So, for
instance, you could associate a text/x-cfile (or whatever mime type
you want for *.c files, something standard would be ideal) with a text
viewer, a text editor, and possibly a compiler.

    Pavel> 2) How about extended attributes for files that belong to
    Pavel> other users and are not writable by me? Should I be allowed
    Pavel> to modify them?

Why should you be allowed to modify other peoples files? I don't see
any reason why you should want to, especially if you don't have any
write access to the file. Unless of course, the implementation is
broken.

    Pavel> 3) How about modifying extended attributes on read-only
    Pavel> filesystems? I want to arrange a certain file to be opened
    Pavel> some way, but I cannot do it because the file is on CD-ROM

Again, why would you want to? EAs have data that represents the
contents of the file. There shouldn't be any need to change the EAs
unless you also change the file contents, too.

    Pavel> 4) Different GUI's may have different understanding of what
    Pavel> EA's they need. Even worse, they may have conflicting
    Pavel> understanding of it.

This is a good point. Some sort of standard needs to be developed.
The only EA I want (not including security ones) is mime-type.  While
others might argue that things like icons, notes, keywords, etc, are
important too, these are not a big issue for me (especially icons).

    Pavel> It may be useful. You may want to associate some files (not
    Pavel> necessarily with a certain extension) with "gcc" or with
    Pavel> "less". You may want to write personal remarks about
    Pavel> e.g. /usr/include/stat.h

Agreed.

    Pavel> But I would prefer to keep such data somewhere under my
    Pavel> $HOME

    Pavel> An apparent problem is with removable media, but other
    Pavel> computers may have different software, different paths,
    Pavel> different GUI's and different icons, so the associations
    Pavel> are not guaranteed to work anyway.

I think you need to change your thinking from

data file ---> application

(which depends on: the data file, the application, and the users
preferences)

to

data file ---> file type ---> application

where the first arrow is represented as EAs, and does not vary unless
the data file changes.


However, I guess this, in a way, is a limitation of the current scheme
for translators, where a file is directly tied to a translator, hence
translators might not be appropriate for CDROMS, for instance.

-- 
Brian May <bam@debian.org>