flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mr. Rich" <mrrich....@gmail.com>
Subject Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs
Date Thu, 24 May 2012 15:48:48 GMT
All I can say is thank you Jeff.  That idea can span far beyond RSLs.

The iframe to increase the limit is gold.  I know in AS3 storage is based
on sub domains also.

To get extra tricky, you can map a few with iframe.

Again, thanks Jeff.
On May 24, 2012 11:39 AM, "Jeff Conrad" <jeffxpx@gmail.com> wrote:

> Hi all,
> I've been lurking on the list for a while now, and I came up with an idea
> to fix the 'no signed RSLs' issue.  It's a little hackish, but it just
> might work.  We might be able to use HTML5 storage technologies like
> LocalStorage and IndexedDB to cache RSLs in the browser like the Flash
> Player asset cache does now.
> I've only done a very small amount of research and no experiments yet to
> see if it will work.  It's been at least a few weeks since this thought
> popped into my head, and I don't want it to stay in my head if someone else
> wants to do it, they should be able to do it.
> Here's what I was thinking of doing.  Use a storage js library like
> lawnchair (http://brian.io/lawnchair/) which abstracts out all the details
> of HTML5 storage and then store and retrieve RSLs as a base64-encoded
> string which can be converted to a ByteArray and loaded via loadBytes just
> like the SDK does now.
> Pros:
>  - There's a somewhat large storage cap.  LocalStorage has an effective cap
> of 2.5-5mb per domain depending on the browser implementation and from what
> little investigation I did.  IndexedDB, which doesn't a lot of supporting
> implementations, has a 50mb limit in Firefox.  IndexedDB is capped in
> Chrome at 5mb unless you make your webapp into a Chrome Web Store app.
>  Then, you can request unlimited storage as part of your manifest.json
> file.  To get more storage, it may be possible to use iframes and
> postMessage() to store and retrieve RSLs on a per-domain basis.
>  - This would work with any SWF you wanted to be an RSL, and it could be
> hosted from any website / cdn.
> Cons:
>  - Relies on JavaScript and multiple differing implementations of local
> storage APIs.  Some of that can be abstracted away with a library, but
> underneath all the abstraction, it's still an issue.  Ideally, if js /
> storage implementations change, you can just upload newer js libraries so
> existing apps wouldn't have to be recompiled to be fixed.
> Other thoughts:
>  - I have no idea what the performance for something like this is like
> because I haven't done any tests.
>  - Automated testing of this functionality can be done using selenium.
> What do you guys think?
> Jeff

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message