I would like to request a feature be made available to the sdk. It is already on the box. I would like to be able to unzip a file.
Since games require a lot of images, I would like to be able to download the whole bundle, and unzip them on the box. That would be much easier than downloading each image one at a time. Also, it would make it easier to apply different “skins” to an app to make them more customizable.
I’ll second that. I believe I’ve asked for before, but I don’t believe we ever got an official response on the subject.
“kbenson” wrote:
I’ll second that. I believe I’ve asked for before, but I don’t believe we ever got an official response on the subject.
LOL 
I knew I would get a second vote from you.
“YungBlood” wrote:
“kbenson” wrote:
I’ll second that. I believe I’ve asked for before, but I don’t believe we ever got an official response on the subject.LOL
Hehe, of course!
It just occurred to me, since the main reason I want zip/unzip is to handle packaging, maybe implementing a simple packaging format without complression wouldn’t be too hard. “tar” comes to mind. Compression can always be handled on the fly from the webserver to the Roku, so it’s not big deal (but it much harder to code).
Yet another one for librokudev. Maybe I’ll work on that after Christmas. Right now, Geoff and I are working on rdTAP and rdClass, both of which offer some very cool features. Hopefully we’ll have those out by Christmas (I think they are actually both complete at this point, so I don’t see why we wouldn’t).
“kbenson” wrote:
Hehe, of course!It just occurred to me, since the main reason I want zip/unzip is to handle packaging, maybe implementing a simple packaging format without complression wouldn’t be too hard. “tar” comes to mind. Compression can always be handled on the fly from the webserver to the Roku, so it’s not big deal (but it much harder to code).
Yet another one for librokudev. Maybe I’ll work on that after Christmas. Right now, Geoff and I are working on rdTAP and rdClass, both of which offer some very cool features. Hopefully we’ll have those out by Christmas (I think they are actually both complete at this point, so I don’t see why we wouldn’t).
I was thinking of packaging. But I was also thinking about something else. Since good games will require a lot more images, it would be nice to be able to tightly compress them as a zip within the pkg. Then you could unzip it into the tmp and effectively have a larger channel without requiring a download of files.
“YungBlood” wrote:
“kbenson” wrote:
Hehe, of course!It just occurred to me, since the main reason I want zip/unzip is to handle packaging, maybe implementing a simple packaging format without complression wouldn’t be too hard. “tar” comes to mind. Compression can always be handled on the fly from the webserver to the Roku, so it’s not big deal (but it much harder to code).
Yet another one for librokudev. Maybe I’ll work on that after Christmas. Right now, Geoff and I are working on rdTAP and rdClass, both of which offer some very cool features. Hopefully we’ll have those out by Christmas (I think they are actually both complete at this point, so I don’t see why we wouldn’t).
I was thinking of packaging. But I was also thinking about something else. Since good games will require a lot more images, it would be nice to be able to tightly compress them as a zip within the pkg. Then you could unzip it into the tmp and effectively have a larger channel without requiring a download of files.
Unless I’m mistaken, Images don’t compress very much when zipped up. I doubt you will get very much space savings.
Image files in formats like png are already compressed. Usually recompressing them with zip results in a very minor reduction on the order of a few percent unless the png compression was pretty bad to start with. I don’t think you’ll be able to fit a significantly larger number of images in your channel just by zipping them.
–Mark
PNG can be loss-lessly (as well as loss-ily) compressed. Look into PNGCrush (pmt.sourceforge.net/pngcrush/) to see if you can reduce the filesize of the images without losing quality(specifically look at the ‘-brute’ and ‘-reduce’ command line arguments for lossless reduction). Your image software may or may not already be doing this, but it doesn’t hurt to look.
I worked with the Winamp skinning community once upon a time, and pngcrush was very popular with them. It reduced overall skin package size, but also lowered memory requirements.
“YungBlood” wrote:
I was thinking of packaging. But I was also thinking about something else. Since good games will require a lot more images, it would be nice to be able to tightly compress them as a zip within the pkg. Then you could unzip it into the tmp and effectively have a larger channel without requiring a download of files.
What I meant when I said “Compression can always be handled on the fly from the webserver to the Roku” was that if the web server supports gzip/deflate encoding, and the Roku supports that encoding (does it? I can’t remember if I tested this), then the compression level of things is really not an issue, since over the wire it’s transparently compressed at the web server and decompressed by the client.
Even if there isn’t a big space savings for images, there still would be for my data files.
Also being able to download one file rather than 50+ would make managing my games much easier. Just a simple card game requires 52+ images. One of my upcoming games will require image sets of around 100 images per set. As I work on pushing the limits of what roku can do, I will be working with more & more images for a single game. As my image count goes up, http overhead gets worse if I have to download each image individually.
If zip bombs are a big concern, I could work with something like tar. I’m just thinking that the box already has built in support for zip.
“kbenson” wrote:
“YungBlood” wrote:
I was thinking of packaging. But I was also thinking about something else. Since good games will require a lot more images, it would be nice to be able to tightly compress them as a zip within the pkg. Then you could unzip it into the tmp and effectively have a larger channel without requiring a download of files.
What I meant when I said “Compression can always be handled on the fly from the webserver to the Roku” was that if the web server supports gzip/deflate encoding, and the Roku supports that encoding (does it? I can’t remember if I tested this), then the compression level of things is really not an issue, since over the wire it’s transparently compressed at the web server and decompressed by the client.
It does, and the roUrlTransfer component automatically adds the “Accepts” header for gzip, so you don’t even have to do any configuration for it.
“TheEndless” wrote:
“kbenson” wrote:
What I meant when I said “Compression can always be handled on the fly from the webserver to the Roku” was that if the web server supports gzip/deflate encoding, and the Roku supports that encoding (does it? I can’t remember if I tested this), then the compression level of things is really not an issue, since over the wire it’s transparently compressed at the web server and decompressed by the client.
It does, and the roUrlTransfer component automatically adds the “Accepts” header for gzip, so you don’t even have to do any configuration for it.
Ok, that will help with speed on data files once I config my server. But I still would like unzip to help me deal with downloading lots of small files.
The functionality is already in the box -
“the Roku box supports .m3u8 files that are compressed via deflate or gzip.”
So they would only require that functionality be utilized for the pkg itself - and ensure there is enough storage for the pkg to fully decompress.
