Since I have namespaces, objects and resources when writing to C must be prefixed by the namespace. However for namespace class exportation, I will need to have it where I can declare the classes which are in the specified namespace for global linkage. So essentially there will be a gigantic array of classes in the given namespace. Then references to these classes are bound by these namespace lists. Built-in namespaces would be included in an internal list which then points to the namespace structure data.


A problem with TAR is that I need to know the size of the file before I can write it. I may have to instead use streamed ZIP files.


So basically this will be the ZIP file format then, since TAR would not work. At least for source code, I would not need permissions or execute bits set. However, my project called zip-compression would better be called zip-file instead. Then I can make a new project which is able to write ZIP files. Since I do not have any compression currently, I can always add that later.


Actually it might be best if it were to become zip-reader-block for block based reading of ZIP files. Another variant could be zip-reader-stream for stream based reading. At least for uncompressed streamed data with no known size, a valid header detected along with a sane size and CRC would determine if data just blindly matches the ZIP data (say a stored ZIP within a ZIP) that precedes it. That could be used to determine when an uncompressed streamed entry with unknown initail size is used.


Personally, I wonder if the supporting 64-bit ZIP files is worth it. Generally for Java ME I would only ever use 32-bit ZIPs. Supporting entries that are very large or ZIPs with lots of files would be more sane than not supporting it. However, I suppose initially I should have a means where I can read/write 64-bit ZIPs but not yet support it for example.


I would suppose that the intended targets for Java ME and SquirrelJME in general, there would really be no need to support 64-bit ZIP files.


Generally my code itself would likely never operate with very gigantic files. Also lightening up the code would simplify things. Also one thing to consider is to remove the data pipe code and just have the deflate decompression be an input stream of sorts.


I would suppose that my ZIP stream writer would be rather simple in its implementation. Generally just need compression or storing. Then I would also need a CRC32 calculator, but that can be generic in either being an output stream or an input stream. Right now for the most part I made the data pipe to allow for buffering and whatnot, however it might not actually be needed much at all. The only issue would be inflating on an output stream. As in, I write deflated data. So I suppose instead I could instead of a DataPipe would just be an input and output stream which is very similar. So something very similar but something very much more direct and less buffered.


Also one thing to consider is that with the builder, instead of using the block based ZIP reader I can use the stream based one instead. Since I have to go through all entries anyway, I do not need to wait for reading the index at all. However, I suppose for the package code I just need to read a single file. It may be faster assuming the entries in the ZIP contents have their sizes before the file starts (otherwise I would be forced to decompress to continue).


What I need is actually a little endian DataOutputStream for ZIP data.