[add-art dev] Caching the updated art images

[Matt Katz]

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
>