Re: Suggestion for file type detection approach

[Edward Jay Kreps <ejk ucsc edu>]

> Don't forget about the waste of traffic and server disk I/O that can be
> generated if content sniffing is used across the network by lots of
> users. :)

I agree that sniffing non-local files is just a bad idea, it seems like
this should be turned off just like the audio thumbnailing of non-local
files is.
 
> Besides performance, big part of the discussion is about manageability.
> Content sniffing is not manageable by users or sysadmins. It can only be
> managed by programmers. IMHO, we should not impose to users (in the way
> it is currently implemented) a feature that, in some cases, get in their
> way and they cannot even call the technical support to walk around it.

There is no reason that this should be such a problem.  Both methods
have difficulties, but quite apart from what method we use to determine
the type of a file, there ought to be a usable method of opening the
file in a different program.

If you think this is a huge problem (I don't, really) then the solution
is not to go back to a known broken method, but allow the user to change
the type of a single file: in Mac OS a file has a default program that
opens it based on type (I think), but the user can choose a different
program, and files always open in the program that last opened them. 
They actually implement this in the filesystem, but there is not reason
it has to be.

This sounds confusing, but all it means is that in addition to caching
the type, we add last-opened-by information.  This is really the only
way of solving the web developer dilemma of having many html files, some
of which are, say, system documentation and should open in the browser,
and some of which are web pages you are editing and should open in your
html editor.  Obviously anyone who edits sound or video files has the
same problem.

> It is possible to educate users about the fact that files must have
> suffixes to be properly identified by the system and that it is
> possible
> to fix wrong suffixes by right-clicking and running the filetype
> detection tool to rename the file properly. The system can also
> intelligently wanr the users when they are about to save or rename a
> file with wrong suffixes.

The point I was trying to make earlier is that Microsoft, which has vast
resources to direct at this problem, still has all kinds of confused
Windows users with incorrectly typed files.  So I really don't think
that their solution is so great.  It isn't that users can't be
educated--they can--it is that users don't want to be educated, and I
don't think they should have to be.  People have better things to do
then memorize filename extensions, not everyone wants to be a computer
nerd.

The point is this: I absolutely agree that doing something automatically
for the user and screwing it up is unacceptable (especially if we don't
provide a way to work around it), but doing something correctly for the
user is a good thing. You seem to believe that the automatic approach
can't be made to predict filetypes as accurately as filename extensions,
but I don't think you have really said why.  You said it was slower, you
said there was no way to recover from an error, but neither of these are
fundamental problems, just implementation bugs.  Frankly the automatic
detection is working really well for me, especially on the many files I
have that don't have extensions so I would be sad to see it go without
any reason.

Thanks,

-Jay