Re: Extended attributes
On 01 Jan 2000 12:49:52 +1100, the world broke into rejoicing as
Brian May <bam@debian.org> said:
> >>>>> "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.
This is somewhat bijective...
*BOTH* associations need to exist.
--> There should be a file type associated with the file.
One could do far worse than use /etc/magic to determine this type.
--> There then needs to be some way of associating methods with the
combination of [file, type].
> eg Macintosh does it the wrong way, where a data file is associated
> directly with an application (IIRC).
Yes, there's a single "number" that is used to determine the
application. That amounts to oversimplifying things.
> 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.
In effect, W98 *also* oversimplifies things. It has the merit that it
"oversimplifies less badly."
> 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).
That would be a good way of associating actions with file types, yes.
> 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.
... And with a print utility ...
> 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.
Good point.
> 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.
This implies that there not only needs to be an indication in
~/.mailcap as to the association of methods with file types, but also,
perhaps, some associations of methods with specific files, for those
unusual cases where you really need to do something other than the
default behaviour.
> 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).
I'm not sure that the EA necessarily needs to go with the file in this
case. I suspect that putting the control information in something
like unto ~/.mailcap
> 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.
Third possibility:
Three associations:
1. [data file] --> [file type]
2. [file type] --> [default application list]
3. [data file, file type] --> [override application list]
--
"Is your pencil Y2K certified? Do you know the possible effects if it
isn't?"
cbbrowne@ntlug.org - <http://www.hex.net/~cbbrowne/lsf.html>
Reply to: