I think the reason for Apple to move to file name extensions is that MacOS X is basically Unix. All those BSD tools can't handle any other metadata than filename, permissions and access/mod dates. Still, it should be possible to access or modify all metadata information from scripts or the command line. It would have been possible to write accessor tools for that, but it looks like Apple chose the easy way.
Which brings me to all the other operating systems of choice, which may partly have file system support for metadata, but certainly not application or tool support. For that to arrive, file system support for metadata must be pervasive --- otherwise, applications would have to decide
What file system is this file going to be saved on?
Does the file system have metadata support?
If yes: Which API is needed to store metadata?
If not: Can the file be stored without metadata?
...etc ad nauseam.
Now, if we do agree that metadata is essentially a good thing, we ought to be able to save it on any proper file system (as a consensus of minimal functionality, I'd suggest long (128-char, at least) filenames without special characters except pathname separator), and it ought to be accessible by regular Unix tools for portability and backwards combatability.
I'd suggest the way that MacOS does it with its applications -- simply package everything into a directory. That directory could contain a file with a fixed name, describing what type file this is (Apple uses "Info.plist" in XML), and any number of data streams -- one, perhaps, for the binary file data itself, a couple for resources, etc. etc. The resulting dictionary (I'll call it a "package") can be manipulated by legacy tools, and there could be library support for the format to make it easy for new tools to make full use of it.
The only problem I see with this is that this directory would have to be encoded for transmission over the net; but that's the problem that John wrote about, and could be solved by simply making a tar file of the directory. That even has the added advantage that there's tool support for tar files on just about any platform, which is more than can be said about MacBinary.
Slashdot Mirror
Which brings me to all the other operating systems of choice, which may partly have file system support for metadata, but certainly not application or tool support. For that to arrive, file system support for metadata must be pervasive --- otherwise, applications would have to decide
I'd suggest the way that MacOS does it with its applications -- simply package everything into a directory. That directory could contain a file with a fixed name, describing what type file this is (Apple uses "Info.plist" in XML), and any number of data streams -- one, perhaps, for the binary file data itself, a couple for resources, etc. etc. The resulting dictionary (I'll call it a "package") can be manipulated by legacy tools, and there could be library support for the format to make it easy for new tools to make full use of it.
The only problem I see with this is that this directory would have to be encoded for transmission over the net; but that's the problem that John wrote about, and could be solved by simply making a tar file of the directory. That even has the added advantage that there's tool support for tar files on just about any platform, which is more than can be said about MacBinary.
Any comments?