Re: Zip-files
Re: Zip-files
- Subject: Re: Zip-files
- From: "Mike Hall" <email@hidden>
- Date: Fri, 14 Jan 2005 05:34:11 -0600
----- Original Message -----
From: "Charles Srstka" <email@hidden>
To: "Fredrik Olsson" <email@hidden>
Cc: "Cocoa-Users List" <email@hidden>
Sent: Friday, January 14, 2005 3:39 AM
Subject: Re: Zip-files
> On Jan 13, 2005, at 12:17 PM, Fredrik Olsson wrote:
>
> > And no I am not interested in Mac specific data, as the source files
> > comes from Windows users.
You might take a look at http://www.gzip.org/zlib/. I believe this is
actually what java implements. C not Objective-C but I have in the past
successfully Mac built it. I wrote a earlier Mac Java JDirect interface to
the built library sort of as an exercise to see how suitable JDirect was for
use with non-Apple toolbox native routines. Could you do C/Java ports of a
sort including it? (Yes) JDirect is gone as a support technology since the
1.4 Cocoa VM, although there is a SourceForge project with a compatible API
that I actually used to implement a Cocoa-Java bridge of a sort.
I have some other java zip related code that I support so my interest goes a
little beyond zlib. I think what I have allows a little more dynamic access
to zips than what java.util.zip provides. That was I think was partly
designed with the jar, war, ear, or in other words some sort of static
archive concept in mind. From the point of view at least say of IDE's I
think zip file access can be more dynamically designed just like normal file
system access. This including easy support for adding, deleting, and
updating on-the-fly files (verifying existence, listing 'directories' and so
on, full file system API support). This working because zip is already
designed in a directory, sub-directory file system type set up.
There are PKZip RFC's and other documents readily available on the internet
fully detailing the format, Huffman compression, and so on. Peter Deutsch a
name coming to mind there but possibly from somewhere else. I'ts been a
while since I actually went through the doc. Although I haven't really even
figured out Huffman myself and I would think you might want to grab at least
those parts from zlib you could implement your own code like javas from
scratch only requiring random access I/O. (Java RandomAccessFile is what my
filesystem code above is based on). I remember in reading the documentation
that some zip feature was designed for platforms that didn't support 'seek'.
So it doesn't necessarily even have to be good random access support. Really
I'd port zlib and implement the random access stuff separately. Actually I
was thinking of doing this IBM mainframe as a 'on my own side project' on my
last job. I didn't get too far. It was mainly curiosity driven with no big
need and theres only so much time usually for on the job side projects.
Somewhat interesting, at least to me, is that when Apple came out with
application bundles where they tried to make directories sometimes behave
like files they called them 'opaque directories'. For what I was doing where
I was trying to make zip files behave more like directories I called my
stuff 'Transparent Random Zip'.
Off-topic my file system type zip code might be seen as interesting just
from the standpoint of a fairly involved java hack exploit involving type
confusion and evil classloaders. I sort of like that in Objective-C type
confusion is seen as a feature not a bug. Although I usually try not to play
this up since I think the 'more dynamic' zip idea is more interesting than
just that I managed a hack. When it works though it is sort of slick. It
allows me to substitute the dynamic zip code for the normal filesystem API
code so that basically you can control which actual class you use when you
want, the normal file API code or the zip specific. What this means is that
you can convince arbitrary java code - without code changes or even
recompiling - that they are working with normal file system files when they
are in fact working with zip entries. Nice when it works. When it doesn't
which is what I was actually looking at yesterday, and could be today, it
can be a real mess. And of course I can't really recommend use of code based
on a hack. The dynamic code can be used without substituting for core
classes I would again emphasize.
So. Yes, depending on your needs you might just get by with running existing
commands. I would give some thought even then to using the java jar command
line tool if you can be reasonably sure it's present. The jar format I think
allows for some meta file information as well as secure signing and other
features that just extend basic zip. Java I think has helped make zip a good
cross-platform file format choice that might be worth some effort beyond
that as well. It probably depends on your need.
Mike Hall mikehall at spacestar dot net
http://www.spacestar.net/users/mikehall
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden