Upon re-reading this I realize that I didn't understand your question.
What it will save us is that in the majority of instances, we will benefit from
the cached RSL.
And we will be able to still push smaller files so that NEW users do not see a
jump in the time that it takes to open the app.
Competition is high in this genre of games, and being the fastest to load is
important. We won "Best social Casino Product of 2013" this year. Maybe if we
were not the fastest to load we might have still won. Maybe not. But we are.
And I would hazard the guess that it played a role. Many ppl already HAVE the
RSL's cached on their machines. I have to offset that benefit by minimizing as
much as possible the hit that any Apache based solution would incur.
As with any social game the first impression is the most important one.
Especially with those who are disposed to spend real money. I know that
TECHNICALLY there are many reasons to just link it statically and forget about
it. But from a business perspective, every shred of speed that we can
statistically extract from the app is worth it.
I can't justify moving all the framework RSL's to our CDN and storing them in
browser only cache instead of perpetual flash player storage. That's why I
asked about local storage hacks. I CAN justify putting a SINGLE file on our
CDN, if it means greater stability (ie: new SDK) and downloading a smaller
amount of bytes than the 4.5.1 RSL's. a few bytes are big money when you are
distributing them to a million ppl.
Unfortunately, that's the reality of the business side of a social app. :(
> From: david_coleman_...@hotmail.com
> To: dev@flex.apache.org
> Subject: RE: SharedLibrary not works with SDK 4.11
> Date: Tue, 3 Dec 2013 19:56:13 -0300
>
> It saves us a great deal of time and resources when we have to release new
> art.
>
> We can break cache on the art asset module and not have to run a full QA
> regression on the main app. This gives us the flexibility as a company to
> deliver constantly changing content to our users w/o forcing them to download
> every file again, or dedicating our time and resources to QA of the
> application when we only want to change a single image in the game list.
>
> It is a logistical and political need as much as it is a technical decision
> to approach it this way.
>
> > From: aha...@adobe.com
> > To: dev@flex.apache.org
> > Date: Tue, 3 Dec 2013 14:43:33 -0800
> > Subject: Re: SharedLibrary not works with SDK 4.11
> >
> >
> >
> > On 12/3/13 2:38 PM, "David Coleman" <david_coleman_...@hotmail.com> wrote:
> >
> > >Actually Alex, what is the biggest culprit in our file is Greensock, and
> > >after that, a whole mess of engine logic needed to handle the interface
> > >with the games. Also some of our legacy animations use Tweener, so for
> > >now I'm cursed with having to include BOTH libs in the main app.
> > >
> > >I also think that 500K is too much and like I said, each version I
> > >whittle it down a little more.
> > >
> > >I've often thought of loading the engine container as a module to remove
> > >another 100K or so from the main app.
> > >
> > >How would i create a custom RSL? Can I automate it via ant to generate
> > >it via the link-reports? I'd like to keep one RSL for ALL files, app,
> > >and modules to increase cache hits, and not hit a different file each
> > >time.
> > >
> > >I'm really curious to experiment with this. It's ok if the browser cache
> > >expires, that's beyond my control, but 99% of the time it will be a
> > >benefit - I'm ok with those numbers.
> > I asked this in the other reply, but how will that save you over a single
> > monolithic SWF? If you're not in the cache, then instead of loading two
> > things, one of which may contain classes you don't need until later, you
> > only load what you need when you need it.
> >
> > -Alex
> >
>
