incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Conrad <jeff...@gmail.com>
Subject [PROPOSAL] Use HTML5 storage technologies as caching for RSLs
Date Thu, 24 May 2012 15:39:19 GMT
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

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