[add-art dev] Caching the updated art images

[Ethan Ham]

Almost done with the switch to using a jar file for images... I think this
solves all the issues (e.g., no need for special utility, no bloating of
data, etc.)


On 6/4/08 11:53 AM, "Matt Katz" <matthew.katz at morelightmorelight.com> wrote:

> I gotta say I think you want to separate the image data from the xml.
> I have a counter proposal, let me know if it makes sense.
> 1. Download add-art.xml - compare a version number element in it to the
> version number element you have in the locally stored copy of add-art.xml.
> If the one you downloaded is newer, overwrite add-art.xml with your new
> version.
> 2. iterate over the image elements in your file.  If an image element
> doesn't have a "cached=true" attribute, begin downloading the image and
> cache it locally.  When it comes down, mark that element as cached=true
> and move on to the next image element.
> 
> While this isn't one step, I think it is an even better scenario if the
> browser gets closed in the middle.
> - You aren't downloading the whole 11 mb at once, more of the extension
> becomes usable as you go.
> - On restart you can just download any of the images that haven't been
> cached yet.
> - You also don't get jpeg bloat due to base 64.
> - You don't need a special utility to construct the xml file.
> - You don't run into the 2 simultaneous http requests limit that an
> extension is allowed.
> 
> If this approach makes sense, I can help if you commit some of the code
> you've done already to the downloadafile branch.  Also, word to the wise,
> you have to construct your xmlhttprequests according to the xpcom
> component style rather than the normal style - the code currently in the
> branch does that.
> 
> Ethan - awesome contribution so far!
> 
> 
>> 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
>>> 
>> 
>> 
>> _______________________________________________
>> 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
>