On Wednesday, Jul 16, 2003, at 12:24 America/Guayaquil, Tim Myers wrote:
Hey Stefano,
Don't you use Mac OS X now? You know what apple really got wrong in the
finder? They use file extentions!!!
I think this is not the case.
OS9- had file attributes to store typing information.
I believe this is true for OSX as well.
That has it's advantages and disadvantages- Unix has this perfectly wonderful system for typing, /usr/bin/file and /etc/magic.
hmmm, a matadata inference system is a good help against lazyness, but it's never as effective as explicit metadata. IMHO, POSIX falls short in that domain and UNIX just tried to work around it with automagic type discovery (which <?xml version="1.0"?> shows it can be a massive mistake!)
Apple moved to unix and the finder doesn't use this system!?!
OSX Finder (and the 'open' terminal command) uses FS metadata to know which application is associated to a given file, not extensions.
Here's a fun exersize.
Take an mp3, post it someplace (ftp, http) download it to your home directory
on a mac and do the same in linux. Double click it in the finder on the mac;
in Nautilus on linux. It will play.
Here's the fun part. Rename that file song.mp3 to song.zip. Download it
again. Double click.
If your download is on HTTP, the wrong mime type is probably given by your web server. In this case, this is not OSX fault at all! It's your web servers!
[in case of FTP, there is no MIME-type associated to the file. One of the many reason not to use FTP]
It shouldn't be a filesystem module poking into the file trying to guess it's
type-- that should be beyond the scope of the file system.
I disagree. This module should kick in only if no type metadata is available, but 'poking into the file' might be an increasingly difficult exercise and might yield unwanted results.
If you have an XHTML page with some inlined SVG, what MIME type is that? XML (goes to my xml editor), XHTML (goes to my browser) or SVG (goes to my vector graphics editor)?
MacOS got it right in separating type from name. POSIX got it dead wrong (and Reiser shows that better design with elegance and simplicity IS possible) and UNIX implementations tried to work around it with autodiscovery.
Which, IMO, in the next few years of XML expansion, will show how crappy the approach is.
NOTE: even web servers that mount one2one the URL space to the FS space share the exact same design mistakes. The Cocoon2 sitemap was introduced exactly to solve those problems.
So, IMO, Cocoon and ReiserFS go hand in hand in improving what it was previously defective in design, the first for URL space and the second for FS space. [I heard that even the next version of windows, longhorn, will have a similar approach implementing an object-oriented file system based on top of parts of sqlserver]
It should be the
shell using a command like file that figures out syntactically and symantically
what the file is and what it can do with it.
Disagree. MacOS approach is, IMO, much better and doesn't yield inconsistent results. Automatic discovery should kick in only where there is no type metadata available and provide a list of options to the user as to what type it can be if more than one match... even if, with XML this could become a real problem, expecially once they are sent gzipped like in openoffice case or compressed SVG)
The problem is much more complex than you outlined.
-- Stefano.
