Your resource files would not be kept in the Curl compiled package cache, unless you somehow encode the data in your Curl source code, as cbarber is talking about.  That does not sound like a convenient or efficient idea.

If you know the resource files (*.jpg, *.mp3) ahead of time, and they are in the project directory, then if you add them as resources to your project with a deploy setting of "copy", then you can have them deployed for OCC.  Using the IDE to deploy the project for OCC will put all the files together into a compressed archive file, curl-archive.car .  Then users install the OCC applet from your website, which will download the compressed archive and expand the archive into the local directory created for use by OCC applets (on Windows, typically a location like file:///c:/Documents and Settings/duke/Local Settings/Application Data/Curl Corporation/Surge/local-root-for/ ).

The use of InflateByteInputStream is a good idea if you don't know the files ahead of time or cannot put them in the project directory.  However, since jpeg and mp3 are already compressed, it would not be that beneficial to be compressing them again.  Other types of files could see a lot of benefit from a compression step though.

In the version 7.0 of Curl OCC, I think there will be a preference for running OCC applets from the local disk copy, while in Curl 6.0 you would run from the network (using your browser cache) if your computer was connected to the network at the time you started your applet using the special URL like curl://occ/http://www.curl.com/developers/occ2/app1.curl