[Sugar-devel] activities using zip files

[James Simmons]

Sascha,

If the Activity creates a Zip file then the Journal automatically 
resumes it in that Activity.  Making Activities use a special MIME type 
when creating a Journal entry doesn't give me anything I don't have already.

Where we have problems is in downloading Zip files from Gutenberg and 
other places that don't do anything special with the MIME type.  For 
instance, Gutenberg has zipped up text files as well as zipped up 
websites (multiple html pages plus illustrations).  Somebody mentioned 
that Browse will eventually be able to save web pages with 
illustrations, etc. as zipfiles for offline reading.  If Browse could 
handle that, you'd also want it to be able to open these Gutenberg zip 
files if they are saved in the Journal, and it would be nice to do it 
with one click.

The format I use for View Slides is sometimes called CBZ.  It's just a 
Zip file containing images with a .cbz suffix rather than .zip.  The 
GNOME desktop recognizes this file type and displays the first image in 
the file as the file's icon.  I don't think there is a MIME type for 
that though.

James Simmons


Sascha Silbe wrote:
> On Wed, May 27, 2009 at 12:34:03PM -0500, James Simmons wrote:
>
>> 5).  When several Activities support the same MIME type (Zip files 
>> are BOUND to be popular) then there needs to be a way of specifying 
>> that a particular Journal entry should be resumed by a particular 
>> Activity by default.
> Actually zip is just a container format and should be handled as such 
> (if possible at all). I.e. zips created by activities should use a 
> MIME type identifying the _contents_, not the generic application/zip.
>
> File formats can be - and often are - nested: OpenOffice documents are 
> xml-inside-zip, some other application might be using 
> xml-inside-tar-inside-gz and source tarballs are 
> (C+Makefile+...)-inside-tar-inside-bz2. Unfortunately, most software 
> using MIME types has very little support for such complexity (only 
> gzip/bzip/compress as "encodings"). While it would be nice for the 
> Journal to handle the full (i.e. nested) type, we'll need to cope with 
> the lack of support in other software (like web servers) for quite 
> some time.
>
> CU Sascha
>