<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

Albert,<br>

<br>

I have decided against creating a new MIME type for my application.  It

turns out that the problems I was experiencing were caused by issues

with the Journal.  In the latest release the Journal has problems

dealing with larger files (30 meg or so).  When you try to use one of

those files in an application the app acts as if no file was specified

at all.  I got a developer key and updated the OS and now my app works

just fine.  It isn't that big a problem to avoid opening the file with

EToys.  My real issue was opening the file with my own app and having

it not working.  I thought having my own MIME type would solve the

problem, but that was only because I didn't understand what the real

problem was.<br>

<br>

James Simmons<br>

<br>

Albert Cahalan wrote:

<blockquote

 cite="mid787b0d920802090332r13ad1190hb774fd6afb190421@mail.gmail.com"

 type="cite">

  <pre wrap="">The faster sugar can phase out MIME the better.

  </pre>

  <blockquote type="cite">

    <pre wrap="">The MIME type of application/zip works, but Etoys is

using that one too.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

Whatever you invent, Etoys will claim it in the next release.

It does not matter if Etoys has any ability to handle the data.

I'm half serious too, as is clear to anybody who has looked at

the list of MIME types claimed by Etoys and tried them.

Almost none make sense. It's like some kind of land grab.

  </pre>

</blockquote>

<br>

</body>

</html>