The filesystem should implement a generic metadata storage for each file. Then it's up to the desktop manager / application to use proper filesystem APIs to create / change / delete specific metadata containing the icon (or a comment, or... other).
What I proposed was basically a stepping stone to this. I thought, since the icon file is so pervasive, it should continue to be visible. But this proposal basically eliminates it entirely. I think it could still be doable while supporting software which does not understand that the icon file doesn't exist as a separate file.
So you have a generic metadata-capable filesystem, but the library with which software interfaces into that filesystem has the "classic" APIs, and the newer APIs. Legacy software using the classic APIs will continue to "see" .info files. For example, when listing out the contents of a drawer, the library would read each file's metadata to see if it contains icon info, and then list out a fake .info file. The updated API would not list that out at all. The software would need to request the metadata specifically.
Keeping backward compatibility with the existing applications is hard, as deadwood already reported. But it's doable.
Specifically, you need two things:
- a filesystem which supports metadata per each file or folder;
- the filesystem implementation which should report a .info file for each existing file or folder (if no .info real file exist for them).
So, the idea is to have a sort of "virtual icon" which is always generated for files or folders which have no .icon file. When an application tries to access it, then the filesystem implementation transparently intercepts it and proceed as follows:
- it checks if there is a specific metadata associated to the file / folder. If yes, it extracts it and gives back the content, as per the application requests;
- if no metadata is found, then it checks (using proper o.s. APIs) if there's a default icon which is usable, and gives it back its content;
- if no metadata and no default icon are found, then it gives back an empty file.
If there's a real .info file present on the device (which is the normal Amiga o.s. scenario) then the filesystem implementation does nothing (it works as usual).
This solution is 100% backward-compatible with all Amiga o.s. applications.
However it has a drawback: the modern filesystem always reports a .info file for each file or folder in the device, even if there's absolutely nothing (I mean: no real .info file neither icon metadata or default icon). Which might be an acceptable solution, anyway.
BTW, you don't need to always check the metadata content: you need to access it only when the icon data is needed (e.g.: its content should be given back to the requesting application).
I think you should try an Amiga/AROS system, the Amiga/AROS icons, to understand how the icons work, which are completely different from the PC/Linux icons, although to separate files, in a sense they are joined.
I'll give you an example, if on Amiga/AROS you make a shortcut of the file on the "desktop", its icon will be moved to the desktop, if you delete it, automatically you will also delete the file, so automatically you will delete both the file and its icon
I think that you should try to understand what people are talking about before replying.
@ascendant
I gave some though to this idea and I see a couple of problems you would have to solve. They all originate with convention that: "A file can be accompanied by .info file. If that's the case, both files need to be managed together". As said this is convention that has been there from late 80s, not something guaranteed by any API. All software created so far was written understanding that such convention exists.
The first problem I see is something @o1i already mentioned. A program will try to operate on .info file after it operated on regular file. If the filesystem operates on the .info file first, then program might survive this or might crash. All depends on how it was written. Majority of software created for 68K won't have sources that can be adjusted as well as some AROS programs comes in binary-only/close source form.
See above for a possible solution.
Another problem to overcome would be more of a question "which filesystem"? If you modify just one of them, say SFS for example, then FAT and NTFS would still have the old behavior. Thus and application would actually need to understand which file system it is running and have two code path - one for "new", one for "old" systems. This would however mean your goal of simplifying applications could not be achieved. Possibly a more general place to do this would actually be the dos.library and I think you already hinted on this with your comment above about classic API and new API.
MacOS creates hidden files to store its metadata (because it has some) on "alien" (non HFS or AFS) filesystems, like FAT32. Something like that could be made for/on AROS or other Amiga-/like o.ses.
NTFS already supports metadata since ages, so embedding icons (or other things) is already possible.
The "only" thing which is needed is having proper FAT32, NTFS, etc. AROS / Amiga o.s implementations which take care of the new icons model, as per my above explanation.
Finally, there comes a challenge of cross-platform development. With the community of developers with have around AmigaOS, MorphOS and AROS is relatively small there is great value for each of the systems if a developer creates application that can be compiled for all three of them. To do that however, the developer expect same API and same behavior across all platforms. If AROS exposes the new API then the 3rd party developer will either not use it, because that's additional work for him or he will end up with two code paths in his application, which does not make the application simpler.
See above: not needed. However AROS developers need to implement the new stuff...
@deadwood: ntfs has something like that. You can have a file associated with a directory and those two will always stay together. Try saving a web page with IE, it saves a .html file and a dir which are glued together (afair)
That's a different thing which doesn't use NTFS's metadata: it's all about the browsers and how they work.
However NTFS is a modern and very advanced filesystem which can be used for the above (and also to natively implement Amiga's comments attached to files / folders).
