Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Wed, 16 Jul 2003 13:29:30 -0500
Subject: Re: Mime-Types
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <20030716132433.B32320@pirouline.sts.jhu.edu>
Message-Id: <704244C0-B7BB-11D7-ABD6-000393D2CB02@apache.org>


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.