[EMAIL PROTECTED] (Tino Schwarze) writes:
> I think, the security argument against JAR is very far-fetched.
> A JAR is basically a ZIP with a META-INF directory containing a
> MANIFEST.MF file. That's it.
> There is a lot of code around for creating / reading ZIP files - I'm a
> bit worried about robustness though; if the directory at the end of the
> ZIP is broken or missing, things get complicated.
I don't think we should use a compressed archive. Instead the binary
data in the archive should be compressed. That allows to choose the
best compression scheme for the data and to combine different
compression techniques in the archive. Compressing the whole archive
again would probably only reduce the size marginally and would add
unneccessary complexity. You robustness argument is also a very good
argument against compressing the whole archive.
> But a hierarchical structure would be cool too. What about mapping big
> parts of the file format to the file system? This way, a lot of
> information can be stored in the hierarchy and it wouldn't be a big
> difference whether to read a file from file system or from archive.
As I pointed out in an earlier mail, I am not sure if a hierarchical
structure in the archive is a good idea. In my opinion the hierarchy
should only be defined in the XML part that describes how the contents
of the archive should be put together. If we apply the document
hierarchy to the archive, it will become painful to keep the XML
description and the archive hierarchy in sync.
Gimp-developer mailing list