How to create a new MIME type for a Sugar activity?

[John Gilmore]

> But seriously, if Etoys was  
> not made the default handler for a mime type (which is not Etoys'  
> fault), what harm does it do to announce its ability to open that file?

The problem here is a conceptual one.  

(1)  Sugar's design imagines the Journal as the user's only interface
     to the Linux file system.  It also assumes that the only thing
     you'd want to do with a file is "open it" with some heavyweight
     application.  It has no concept of a shell, which allows
     independent commands to be easily applied to one or a range of
     files ("grep -i copyright *.c").  It's borrowing from the
     Macintosh here, which shipped without a hierarchical filesystem,
     and associated an Application with every file (in a "resource fork"
     of each file which contained application identifiers).

(2)  For files *created* by an Activity, this sort-of works; the Journal
     merely re-invokes that Activity (assuming it still exists).

(3)  The problem is files *not created by an Activity*.  It's simplest
     if these merely don't exist.  But that means eliminating the ability
     to access external media (networked file systems, USB memory sticks,
     or SD cards).

(4)  Everything that follows beyond here is chaos -- chaos on which numerous
     bug reports have been filed, chaos that has caused one developer to
     pick a new MIME type for his ZIP files, etc.

Because the "invoke the creating Activity" model doesn't work for random
files inserted into the system, there is *nothing* that Sugar can do that
will seem reasonable.  It'll all be unreasonable from one angle or another;
to one user or another.  Scanning every file on a terabyte USB drive is
unreasonable.  Dropping index-file crumbs on external media is unreasonable.
Assigning mime-types to files and activities to mime-types is unreasonable.
The whole concept at root is unreasonable.

I think the fix is to drop the Journal-as-god model -- not to keep
trying to cram ten pounds of files into a one-pound journal concept.

Expect users to access the filesystem with a filesystem browser -- or
a shell.  Therefore, provide good ones, that integrate with
activities.  Don't try to make the Journal manage everything, even the
things it manages extremely poorly.  Make the filesystem hierarchy
readily discoverable.  Stop trying to hide this very useful concept
from the end users.  Follow the Mac of 2008 rather than the Macintosh
of 1984.  (The Macintosh upgraded to a hierarchical filesystem in
1985, one year after its introduction.)

	John Gilmore