views:

22

answers:

1

I sort of want to do the reverse of this.

Instead of unzipping and adding the collection files to S3 I want to

On user's request:

  1. generate a bunch of xml files
  2. zip the xml files with some images (pre-existing images hosted on s3)
  3. download zip

Does anybody know agood way of doing this? I think I could manage this no problem on a normal machine but Heroku complicates things somewhat in that it has a read-only filesystem.

+1  A: 

From the heroku documentation on the read-only filesystem:

There are two directories that are writeable: ./tmp and ./log (under your application root). If you wish to drop a file temporarily for the duration of the request, you can write to a filename like #{RAILS_ROOT}/tmp/myfile_#{Process.pid}. There is no guarantee that this file will be there on subsequent requests (although it might be), so this should not be used for any kind of permanent storage.

You should be able to pretty easily write your generated xml files to tmp/ and keep track of the names, download and write the s3 files to the same directory, and (maybe?) invoke a zip command as long as the output is in tmp/, then serve the file to the browser with the correct mime type to prompt a download. I would only be concerned with how big the filesize is and if heroku has an undocumented limit on what they'll allow in the tmp directory. Especially since you are only performing this action for a one-time download in the duration of a single request, I think you have a good chance of being able to do it.

Edit: Looking around a bit, you might be able to use something like RubyZip to create your zip file if you want to avoid calling system commands.

Brett Bender
Alright Brett, this sounds like a winner. First of all, I reckon we'd only need the zip for the duration of the request. If it's needed any longer we can shimmy it along to s3... Yes, this sounds doable. Cheers!
ro