Hi, tino.schwarze@xxxxxxxxxxxxxxxxxxxxxxxxx (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. Sven
