Re: Icons of program

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On 22 Apr 1998, Miroslav Silovic wrote:

At 4) can be improved by providing different storage algorithms for
different types of files:
-) GNOME specific files: can use a special format from the beginning, that
   specifies a resource/data fork.
-) shell scripts, binaries, etc. can be made to contain
   the resource fork.
   *) binaries on ELF system may use a ELF section to store it's
      resources.
   *) shell scripts etc. will probably not need much resources,
      (icons, usage info, DnD info, etc.)
      so it's probably ok to encode the resources in comment lines
   *) other extensible formats: each needs a special file handle adaptor
      :(
-) nonextensible file formats (by design or by nondocumentation):
   Here we can store the resource fork in a .info file.

Now in most cases you have reduced the inode cost, and interoperability
with Unix commands.

And in many cases you won't need .info files, because the default still
should come from a file command/extension heuristic.

> 4)
> 
> + works passably well with existing tools
Even better with tools we have the source for, like the GNU file utils.
:)
> + works well with mounted filesystems and removable media
Yep:)
> + simple to implement
Not that simple if you go for all possible adaptors from the beginning.
But reasonably easy to implement: define the API, do the .info file case,
and develop the special cases with time :)
> + users can easily share metadata
> - high inode cost
By storing the metadata if possible in the same file this is even a lesser
problem. (Not that I'd consider it a huge problem from the beginning :) )
> - 'ls' gives litter
Again, the ideal would be for most files to have infile representations,
and GNU fileutils are patchable :)

Andreas