Why bother with using gzip on the file? Compress the data before putting it into the custom properties (see the 'compress' function). This eliminates yet another external dependency (yes, I know that the compression ratio will be slightly less, but the resulting code will be more portable, and not rely on having the user install gzip manually, or need to deal with tracking it externally...)

Of course, you could also try reading the stack file back as binary data and run compress() on that, but it would be somewhat messier.

It would also require more than the size of the file(s) to be compressed as temporary space on the drive:

The size of the files, in the form of the original files.
The size of the files, in the custom properties.
More space (less than the size of the files), in the gzipped version of the file.


You could help to further reduce this by deleting the temporary stack file before writing out the compressed version...


Also, I would recommend a custom property set rather than using the properties directly; this should help to avoid name conflicts (if a file has the name of an internal Rev property, such as a file named "foregroundColor" -- you never know).


So then something like this (plus error checking code, etc.):

on archiveFile intoStack, fileName
put compress(URL ("binfile:" & fileName)) into the dataFork[fileName] of intoStack
put compress(URL ("resfile:" & fileName)) into the resourceFork[fileName] of intoStack
end archiveFile


on extractFile fromStack, nameInArchive, fileNameToCreate
put decompress(the dataFork[nameInArchive] of fromStack) into URL ("binfile:" & fileNameToCreate)
put decompress(the resourceFork[nameInArchive] of fromStack) into URL ("resfile:" & fileNameToCreate)
end extractFile


On Nov 9, 2004, at 10:25, [EMAIL PROTECTED] wrote:

Perhaps I'm missing something, but it seems to me that it should be
possible to create a Rev-only compression utility which can handle any number of
files, on any platform that Rev supports.


Step one: Create a new stack.
Step two: Do a binfile read of whichever file.
Step three: Stick the binary data of that file into a custom property of
your new stack.
Step four: Repeat 2 and 3 as needed, until there are no more files to
compress.
Step five: Use gzip to compress the resulting stack.


   Can anyone think of a reason that this technique *wouldn't* work?
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution


-----------------------------------------------------------
Frank D. Engel, Jr.  <[EMAIL PROTECTED]>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.
$




___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to