I wrapped up the CFZIP portion of my work on CFWACK last night and I came across a cool feature. Did you know that you can add fake/virtual/you get the idea files to a zip? If you use CFZIP to create a zip you can specify a file or folder. This data has to exist on the file system. However - if you make use of the child cfzipparam tag, you can add a file directly from a variable. Consider the following simple example:
<cfset zipFile = expandPath("./zp.zip")>
<cfzip file="#zipFile#" action="zip">
<cfzipparam content="#repeatString('Simple Text',999)#" entrypath="simple.txt">
<cfzipparam source="#expandPath('./unzip.cfm')#" entrypath="/sub/unzipfile.cfm">
</cfzip>
This code sample adds two entries to a zip file. The first is a string. I used repeatString with a count of 999 so I could test how well it compressed. The second zipparam tag uses a real file name - but note how I change both the name and folder for the file.
The only thing missing is the ability to store zip data itself into a variable. When making a zip, the file attribute is required. It would be nice if we could specify "name" and have the binary data stored there. Then we could serve up 100% completely virtual zips to users. (Obviously that could be a bit intensive so you would need to use it with care.)
Archived Comments
Yeah, that is one of the things I was thinking (file requirements). Going old school with the zip Java libraries, you could always just write to a byte stream instead of a file output stream. Then you just have the binary in memory.
I with the CFImage people talked to some of the other "departments" as there are a number of CFImage features that *should* be used elsewhere such as:
- Saving to a variable
- reading in both RELATIVE and expanded paths
Yeah,
I remember having a similar conversation with you a while back Ben about your zip utility and the benefits to me of being able to work 'in memory' with compressed data.
Its somthing I never got around to testing for processor and memory usage, but I serve a lot of data through my web services some of which is pretty substantial stuff and bandwidth for the recieving client is a big issue, so I always compress the data before I ship it out.
At the moment that requires writing the zipped data to disk, reading its brinary which is served to the client, and then deleting the zipped data from the file system, it works a charm like this, I just hate writing files like this so regularly to the file systemm, it'll only be a matter of time untill it falls over.
Somthing which procudces an in memory blob would be great, I'm sure memory usage wouldnt be a massive issue, unless we're talking about massive files, but even if we were we're talking about very short periods of time it would be sitting in memory in the local var scope, It's just about finding the most efficient way of handling it.
Rob