[add-art dev] Caching the updated art images

[Ethan Ham]

Yep, what I'm working on is avoiding having to update the extension to get
new images and I'm storing the images on the disk.

What I implemented was packing the image data into an XML file (i.e., I'm
not storing URLs to the jpegs, I'm storing the actual jpegs).  I took this
approach because I had misunderstood and thought it was the preference to
download the images as XML (I guess what was really meant was download URLs
to the images). 

Anyway, once that XML file is downloaded, I unpack the images and store them
locally as JPEGS.

I actually like that the images are packed up into one file... It make many
things easier (e.g., there's a limit of having no more than 6 XMLHttpRequest
requests simultaneously, I don't have to worry about the case when the user
closes the browsers before all the images are downloaded, etc.).

However, there is the problem with the XML file bloating the jpeg file size.

So I think what I'll do is try switch to having the Jpegs packed up in a jar
file.

Ethan 




On 6/4/08 10:57 AM, "Jamie Wilkinson" <jamie at tramchase.com> wrote:

> I'm not totally clear on how this works... so it's an XML file
> embedded in the chrome that contains base64 versions of the images?
> 
> It's definitely a step in the right direction, but ideally the XML
> definition would be downloaded and stored in the profile directory,
> read on load, and then the images it references downloaded from the
> server. This way we'd be able to avoid needing to issue an update of
> the extension with each show (and we could theoretically have multiple
> add-art subscriptions loading a large # of possible "shows"
> simultaneously, etc)
> 
> So it'd be preferable if the image files were being read from disk
> rather than base64 encoded. Reading from an XML file at all is
> definitely a huge step in the right direction, though! Great work Ethan
> 
> -jamie
> 
> On Jun 4, 2008, at 10:04 AM, Ethan Ham wrote:
> 
>> Here's something that might be an issue: putting the jpegs into xml
>> makes
>> the data twice as heavy (~11MB instead of ~6MB).  This is because
>> the image
>> data has to be converted to Base64 so as to avoid breaking the xml.
>> 
>> Is 11MB acceptable for a download size?
>> 
>> 
>> On 6/3/08 6:17 PM, "Ethan Ham" <ethan at ethanham.com> wrote:
>> 
>>> I'm pretty close to having the art updating nicely (along with a
>>> utility for
>>> packaging the art into xml for download).
>>> 
>>> But I wanted to check and make sure people are happy with how I'm
>>> caching
>>> the art... I'm moving the art images out of the .jar file and have
>>> them
>>> simply residing in an "images" folder under the chrome folder.
>>> 
>>> I looked around briefly to see if there's a way to dynamically
>>> update a jar
>>> file using Javascript, but didn't see anything... So I figured it
>>> probably
>>> wasn't a big deal if I simply have the jpegs in an uncompressed
>>> directory.
>>> 
>>> Ethan
>>> 
>>> 
>>> _______________________________________________
>>> Supperclub mailing list
>>> Supperclub at lists.add-art.org
>>> http://lists.add-art.org/listinfo.cgi/supperclub-add-art.org
>>> 
>> 
>> 
>> _______________________________________________
>> Supperclub mailing list
>> Supperclub at lists.add-art.org
>> http://lists.add-art.org/listinfo.cgi/supperclub-add-art.org
> 
> _______________________________________________
> Supperclub mailing list
> Supperclub at lists.add-art.org
> http://lists.add-art.org/listinfo.cgi/supperclub-add-art.org
>