You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by FRANKLIN GARZON <fg...@hotmail.com> on 2013/12/02 16:05:09 UTC
SharedLibrary not works with SDK 4.11
I have some problemas with SDK4.11 about the sahred library, please see this bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3674828 , ADOBE says is not for this product.
Who can help us?
Thanks.
Franklin Garzón
*Lucha hasta alcanzar tus sueños*
Re: SharedLibrary not works with SDK 4.11
Posted by Paul Hastings <pa...@gmail.com>.
On 12/2/2013 10:05 PM, FRANKLIN GARZON wrote:
> I have some problemas with SDK4.11 about the sahred library, please see this
> bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3674828 , ADOBE says is
> not for this product. Who can help us? Thanks.
i *think* that's because you're mixing RSL across SDK versions or are simply
missing one for 4.11. are you using modules? i believe the RSL would need to be
in the dir as your modules that use them.
might as well clear your brower's cache then test again just to be sure.
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
that's 566k of code... the code is mostly the networking layer, and facebook interface controllers.
The 3 mb of assets load with the preloader and are broken into 2 modules so we can push art changes w/o pushing a whole new client.
The preloader is 33% of the main loading screen - what happens is you don't see
the transition between preloader and application because I designed it
that way, so it looks like a single process. Basically I am already late loading the assets, but it is a requirement that the app be ready for interaction the moment the "startup" is done.
unfortunately, most of the assets are required. for instance at least 1.5 to 2 mb is consumed by the game icons which the user must see instantly, and the game order is dynamic so we can't separate them into multiple pages to lower the load. Some minor optimizations can be made, and believe me, every few weeks I'm shaving a few K here or there. But not enough to add hundreds of K in statically linked libs.
when i build (in debug) with static linking the size is 2,749,998 bytes vs 1,262,589 bytes
in release there is a similar proportion:
1,225,769 bytes vs 609,402 bytes. (with Ant builds these numbers are slightly smaller, which is where i get the 566K for our upcoming release).
basically the main file contains all the networking etc... this is because the game must be "instant-on" users often claim gifts and enter the game in a flow which leads them directly to a popup or a slot, which means that the moment load is done, the app must be in gear ready to go.
is it possible to combine the framework rsls into a single file, and load it instead of the "standard" framework rsl's? So instead of loading 5 different rsls, I load a single optimized file that has only the classes needed for the app and its modules?
The standard rsls come to 1.41MB and the difference in release is 0.58 MB... obviously I'm not using the majority of the flex code base... can I strip this down somehow?
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Tue, 3 Dec 2013 10:20:07 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> Hi David,
>
> So you are saying that there is 566K in non-Flex code and assets to
> generate the first screen (after the preloader)? How much of that is
> assets and how much is code? And what Flex classes are used in that first
> screen? Usually, folks take a second after seeing the first screen before
> they act on it, and you can often do a bunch of downloading and
> initializing in that time. If you move everything not required for the
> first screen to a late-loaded module, you might find that the total
> framework load goes down and static linking becomes possible. That
> wouldn't be true for some app that has a DataGrid on the first screen, but
> I don't think I'm seeing heavyweight components on your first screen.
>
> -Alex
>
> On 12/3/13 6:41 AM, "David Coleman" <da...@hotmail.com> wrote:
>
> >http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmarks
> >&count=18&fb_bmpos=3_18
> >
> >
> >
> >
> >
> >the main file (for the upcoming version) is 566k, currently it is
> >slightly over 600K, the assets are ~3 mb and i have implemented most
> >popups as external modules, to ensure that they load from cdn only one
> >time per session.
> >
> >
> >
> >
> >
> >The main application is a spark application. I use only simple objects,
> > Group, List etc... nothing uber fancy. Most of the heavy lifting is
> >done with AS3 for speed.
> >
> >
> >
> >
> >
> >We have a very large number of users. I can't statically link the libs
> >because ppl expect the blinding fast load that I have achieved. 566K
> >loads in the blink of an eye on even mediocre systems/connections.
> >
> >
> >
> >
> >
> >Personally I would prefer to statically link the framework because RSL's
> > are yet another hit the browser has to make, but we need the users to
> >get into the game and play as fast as possible. I have maintained the
> >fastest load in our category on facebook for
> >nearly a year now. :) I intend/need to keep it that way.
> >
> >
> >
> >
> >
> >so your short answer is "a very big, yet very, very SMALL and optimized
> >facebook app" which is exactly why i have to use them :)
> >
> >
> >
> >
> >
> >Any way around this limitation would open the door for me to promote and
> > fast-track the adoption of Apache Flex. I need small and I need fast.
> > The rest is academic. Once I have the tools, I'll make it happen, and
> >we will migrate to Apache Flex. Our target
> >Flash Player version is 10.3 for maximum penetration.
> >
> >
> >
> >
> >
> >If there is any glimmer of hope to accomplish this... tell me, and let
> >me know how I can help.
> >
> >> From: aharui@adobe.com
> >> To: dev@flex.apache.org
> >> Date: Mon, 2 Dec 2013 11:22:26 -0800
> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >>
> >>
> >>
> >> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com>
> >>wrote:
> >>
> >> >Having not tried this solution myself, this is pure speculation... but
> >> >couldn't local storage store this? set domain to be "*" and retrieve
> >>it
> >> >from the public svn repo. if not present the RSL manager can load it
> >>up
> >> >and in this way we can sign it with our own Cert and validate that cert
> >> >independent of Adobe? Would this be workable?
> >> I think you'd hit local storage limits.
> >>
> >> >RSL's are the only reason that I hesitate to migrate our Facebook app
> >>to
> >> >apache. it will kill our CDN.
> >> >
> >> Just curious: Have you actually measured the difference without RSLs?
> >>How
> >> big a Facebook app is this?
> >>
> >> -Alex
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
Couple of things:
1) Regarding size differences for a simple module with RSL or static
linking, I suspect the difference is that the static version doesn't have
RSL management code injected into it. But in a more complex module that
uses framework classes not used by the main app, the module must contain
those framework classes when statically linked unless those classes are in
a shared code module and also externally linked. I'm encouraging you to
switch to static-linking not because the modules will be smaller (although
with enough work you can make them smaller), but because the probability
your customer will have to download the RSLs is increasing every day, and
the total download time will be greater if you are using RSLs than if you
static link.
2) Regarding your question about optimization of embeds, there are two
factors involved. A) The module subsystem was meant to allow for modules
to be unloaded. B) The compiler is not going to take the time to do flow
analysis to determine when classes will be verified, so the entire class
dependency tree referenced by the main app must be linked into the main
app by default, unless you tell the compiler otherwise.
So, by referencing the module class in the main app, you are not only
adding it and its dependencies to the class dependency tree, but putting
it in the main applicationdomain, so those classes cannot be unloaded.
You can force the external linking of some of those classes/assets only if
you know the verifier isn't going to throw an exception first.
You may want to manually control the contents of the link-report that is
used to optimize the module. Flash Builder doesn't know how to do this,
so you'll have to use Ant and store the desired link-report somewhere or
auto-generate it some how.
But basically, there are enough options in the compiler to control which
classes go in which SWF. But Flash Builder cannot do it for you
automatically. And by choosing Apache Flex, you can make changes to the
SDK that may be needed to better optimize your statically linked SWFs.
And I would still recommend deeper analysis (if you have time) of the 600K
you say is needed to generate the first screen. That still sounds like
too much to me.
-Alex
On 12/4/13 8:20 AM, "David Coleman" <da...@hotmail.com> wrote:
>
>
>
>First I made a simple application which you can see at:
>https://github.com/davidcoleman007/AppWithOptimizedModules
>
>First, I tested WITHOUT referencing the module, just compiling with an
>application and a module, but not actually referencing the module in the
>application. I ran a grid of the main app and one of the modules, using
>both static link/RSLs and optimized/normal module compilation. here are
>the VERY interesting results (with debug compilation):
>
>(lobby == main app)
>//----------------------------------
>//---------- with RSLs -------------
>// optimized
>// inbox 378,681 bytes
>// lobby 1,259,400 bytes
>// normal
>// inbox 390,652 bytes
>// lobby 1,259,402 bytes
>//----------------------------------
>//--------- static link ------------
>// optimized
>// inbox 374,383 bytes
>// lobby 2,745,913 bytes
>// normal
>// inbox 1,136,169 bytes
>// lobby 2,746,063 bytes
>
>Optimized compilation of a module created a SMALLER main file and SMALLER
>module file with both RSLs and static linking - not a great surprise,
>since we all know that in theory optimization should do just that.
>
>However what REALLY surprised me and I suspect will surprise others, is
>this: using static linkage, my optimized module was SMALLER than with
>RSLs.
>
>So on the surface it really appears that Alex is right. Static is the
>way to go.
>
>BUT!!!
>
>then i made a reference to the module in the main application, as you can
>see in the git repo.
>
> import mx.events.FlexEvent;
> protected var module:AnOptimizedModule;
> protected function
>onCreationComplete(event:FlexEvent):void {
> }I did nothing with the module, i just referenced
>it:
>
>here are the results:
>//----------------------------------
>//---------- with RSLs -------------
>// optimized
>// module : 73,116 bytes
>// app : 7,411,954 bytes
>// normal
>// module : 7,407,431 bytes
>// app : 7,411,955 bytes
>//----------------------------------
>//--------- static link ------------
>// optimized
>// module : 67,875 bytes
>// app : 7,906,020 bytes
>// normal
>// module : 7,825,665 bytes
>// app : 7,906,020 bytes
>
>as you can see, the compiler is clearly smart enough to move the big
>embedded image OUT of the module and include it in the main app, but it
>is not capable of the reverse which is to exclude it from the main app,
>depending on its presence in the module.
>
>I know that this can be worked around with Interfaces, and tbh, that's
>what i've done. but it's a workaround. the compiler should be smart
>enough to leave [embed]'s in the module and not include them in the main
>app. It's smart enough to move them OUT when you optimize the module.
>Why can't it leave them IN instead, which would be the more logical
>behavior? After all that is why a developer would most likely create a
>module in the first place. And since a module will never be instantiated
>w/o loading the corresponding SWF file, what point could there possibly
>be for including the binary part of the class definition in the main app
>when it references it? If it were a STATIC member of the module class
>then i would understand it. but it is a public instance property...
>Something here smells fishy to me.
>
>At the end of the day I'm still convinced that the compiler should behave
>differently, but I see that Alex is quite right about static linking.
>This is very encouraging!!! Hopefully sometime next year we can add a
>facebook game to the list of applications that use Apache Flex! (don't
>expect it soon, I'm up to my nose in a bazillion things, but this is
>definitely on my "really-cool-thing-i-wanna-do" list). :)
>
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Date: Tue, 3 Dec 2013 20:12:32 -0800
>> Subject: Re: SharedLibrary not works with SDK 4.11
>>
>> Wow. I don't think it is supposed to do that. Please create a simple
>> test case and create a JIRA issue.
>>
>> -Alex
>>
>> On 12/3/13 5:53 PM, "David Coleman" <da...@hotmail.com>
>>wrote:
>>
>> >For instance i have an app in flash builder with a boat load of modules
>> >
>> >I set one of these modules to be optimized for MyApp.mxml
>> >
>> >the embedded images in MyOptimizedModule end up in MyApp.mxml.
>> >
>> >The good thing is that MyApp and MyOptimizedModule can now be
>>statically
>> >linked w/o doubling its size. the bad thing is that now I have
>>defeated
>> >the purpose of putting my assets in the module.
>> >
>> >can I optimize a module for MyApp without all of its embedded assets
>> >ending up in the optimization target?
>> >
>> >It is my understanding that optimizing a module for a specific
>> >application ends up removing all embedded assets from the module and
>> >storing them in the application.
>> >
>> >If you want i can reproduce this in a few example projects and post it
>>up
>> >on my git.
>> >
>> >> From: aharui@adobe.com
>> >> To: dev@flex.apache.org
>> >> Date: Tue, 3 Dec 2013 17:19:06 -0800
>> >> Subject: Re: SharedLibrary not works with SDK 4.11
>> >>
>> >> I don't understand the part about embedded assets. Can you provide
>>more
>> >> details? The -externs option should let you keep any class out of
>>any
>> >>SWF.
>> >>
>> >> You can create a shared code module or pack other classes needed by
>> >> modules onto extra frames of the main SWF.
>> >>
>> >> -Alex
>> >>
>> >> On 12/3/13 4:05 PM, "David Coleman" <da...@hotmail.com>
>> >>wrote:
>> >>
>> >> >I do agree with your numbers, (how could I not - they are spot on).
>> >>The
>> >> >primary issue is that WE host the rsl or the static link difference.
>> >>and
>> >> >the static link difference affects the size of our modules too. So
>> >>it's
>> >> >100% more for modules, and since we have 7.8 MB of modules (18
>> >>different
>> >> >popups each with animations/hd graphics etc), then we are talking
>>about
>> >> >static linking costing a lot more.
>> >> >
>> >> >If i can customize an RSL to service all 18 modules and the main app
>> >>and
>> >> >only have to distribute one file, that is even better for a new user
>> >>than
>> >> >the Adobe RSL's... ok we have to pay for the CDN costs... but it's
>>less
>> >> >than an extra 7.8 MB of static links for all our modules.
>> >> >
>> >> >Harbs pointed out the exact reason RSL is so critical to our use
>>case.
>> >> >Modules are doubled.
>> >> >
>> >> >Now, if the modules could only statically link what is lacking in
>>the
>> >> >static links of the main application, with out optimizing them and
>> >> >pushing all the embedded assets to the main application... kinda
>>like a
>> >> >"half-optimized" module, then static link could really work for us.
>> >>but
>> >> >as long as an optimized module will push all the assets into the
>>main
>> >> >app, i can't optimize them to share the static links. so they need
>> >>their
>> >> >own static links...
>> >> >
>> >> >Maybe this is something that can work!
>> >> >
>> >> >how can i optimize a module to share the static links of the main
>>app
>> >> >without pushing all the embedded assets in the module to the main
>>app?
>> >> >does mxmlc include a metatag to exclude a class (embedded asset)
>>from
>> >> >module optimization? so it would stay in the module while i
>>optimize
>> >>it
>> >> >for the main app, and then only have to statically link the few bits
>> >>and
>> >> >pieces that are lacking in each.
>> >> >
>> >> >> From: aharui@adobe.com
>> >> >> To: dev@flex.apache.org
>> >> >> Date: Tue, 3 Dec 2013 15:51:44 -0800
>> >> >> Subject: Re: SharedLibrary not works with SDK 4.11
>> >> >>
>> >> >> OK, so let me make sure I understand:
>> >> >>
>> >> >> For first time users, they have to download 3MB of Assets and the
>> >>600K
>> >> >>SWF
>> >> >> and hopefully not the 1.4MB's of framework RSLs.
>> >> >> For returning users, 3MB Assets and 600K SWF is hopefully in the
>> >>browser
>> >> >> cache.
>> >> >>
>> >> >> If you switch to Apache Flex:
>> >> >> First-time users will have to download either
>> >> >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
>> >> >> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
>> >> >>
>> >> >> So, Apache Flex statically linked is another 600K and represents
>>an
>> >> >> additional 12% in download time.
>> >> >>
>> >> >> I don't know what the RSL penetration is of Flex 4.5.1, but every
>>day
>> >> >> folks are buying new computers and there are fewer and fewer Flex
>> >>4.5.1
>> >> >> apps out there in the world so the probability your first-time
>> >>customers
>> >> >> will have those RSLs is diminishing. Over time, more and more of
>> >>your
>> >> >> customers will be downloading the 1.4MB of framework RSLs as well,
>> >>and
>> >> >>the
>> >> >> statically linked solution will be the smaller download.
>> >> >>
>> >> >> Have you used ItDepends or a similar link-report analyzer to see
>>how
>> >> >>much
>> >> >> of that 600K is Greensock, Tweener and other stuff?
>> >> >>
>> >> >> -Alex
>> >> >>
>> >> >> On 12/3/13 3:11 PM, "David Coleman"
>><da...@hotmail.com>
>> >> >>wrote:
>> >> >>
>> >> >> >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_007@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: aharui@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"
>> >><da...@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
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
First I made a simple application which you can see at:
https://github.com/davidcoleman007/AppWithOptimizedModules
First, I tested WITHOUT referencing the module, just compiling with an application and a module, but not actually referencing the module in the application. I ran a grid of the main app and one of the modules, using both static link/RSLs and optimized/normal module compilation. here are the VERY interesting results (with debug compilation):
(lobby == main app)
//----------------------------------
//---------- with RSLs -------------
// optimized
// inbox 378,681 bytes
// lobby 1,259,400 bytes
// normal
// inbox 390,652 bytes
// lobby 1,259,402 bytes
//----------------------------------
//--------- static link ------------
// optimized
// inbox 374,383 bytes
// lobby 2,745,913 bytes
// normal
// inbox 1,136,169 bytes
// lobby 2,746,063 bytes
Optimized compilation of a module created a SMALLER main file and SMALLER module file with both RSLs and static linking - not a great surprise, since we all know that in theory optimization should do just that.
However what REALLY surprised me and I suspect will surprise others, is this: using static linkage, my optimized module was SMALLER than with RSLs.
So on the surface it really appears that Alex is right. Static is the way to go.
BUT!!!
then i made a reference to the module in the main application, as you can see in the git repo.
import mx.events.FlexEvent; protected var module:AnOptimizedModule; protected function onCreationComplete(event:FlexEvent):void { }I did nothing with the module, i just referenced it:
here are the results:
//----------------------------------
//---------- with RSLs -------------
// optimized
// module : 73,116 bytes
// app : 7,411,954 bytes
// normal
// module : 7,407,431 bytes
// app : 7,411,955 bytes
//----------------------------------
//--------- static link ------------
// optimized
// module : 67,875 bytes
// app : 7,906,020 bytes
// normal
// module : 7,825,665 bytes
// app : 7,906,020 bytes
as you can see, the compiler is clearly smart enough to move the big embedded image OUT of the module and include it in the main app, but it is not capable of the reverse which is to exclude it from the main app, depending on its presence in the module.
I know that this can be worked around with Interfaces, and tbh, that's what i've done. but it's a workaround. the compiler should be smart enough to leave [embed]'s in the module and not include them in the main app. It's smart enough to move them OUT when you optimize the module. Why can't it leave them IN instead, which would be the more logical behavior? After all that is why a developer would most likely create a module in the first place. And since a module will never be instantiated w/o loading the corresponding SWF file, what point could there possibly be for including the binary part of the class definition in the main app when it references it? If it were a STATIC member of the module class then i would understand it. but it is a public instance property... Something here smells fishy to me.
At the end of the day I'm still convinced that the compiler should behave differently, but I see that Alex is quite right about static linking. This is very encouraging!!! Hopefully sometime next year we can add a facebook game to the list of applications that use Apache Flex! (don't expect it soon, I'm up to my nose in a bazillion things, but this is definitely on my "really-cool-thing-i-wanna-do" list). :)
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Tue, 3 Dec 2013 20:12:32 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> Wow. I don't think it is supposed to do that. Please create a simple
> test case and create a JIRA issue.
>
> -Alex
>
> On 12/3/13 5:53 PM, "David Coleman" <da...@hotmail.com> wrote:
>
> >For instance i have an app in flash builder with a boat load of modules
> >
> >I set one of these modules to be optimized for MyApp.mxml
> >
> >the embedded images in MyOptimizedModule end up in MyApp.mxml.
> >
> >The good thing is that MyApp and MyOptimizedModule can now be statically
> >linked w/o doubling its size. the bad thing is that now I have defeated
> >the purpose of putting my assets in the module.
> >
> >can I optimize a module for MyApp without all of its embedded assets
> >ending up in the optimization target?
> >
> >It is my understanding that optimizing a module for a specific
> >application ends up removing all embedded assets from the module and
> >storing them in the application.
> >
> >If you want i can reproduce this in a few example projects and post it up
> >on my git.
> >
> >> From: aharui@adobe.com
> >> To: dev@flex.apache.org
> >> Date: Tue, 3 Dec 2013 17:19:06 -0800
> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >>
> >> I don't understand the part about embedded assets. Can you provide more
> >> details? The -externs option should let you keep any class out of any
> >>SWF.
> >>
> >> You can create a shared code module or pack other classes needed by
> >> modules onto extra frames of the main SWF.
> >>
> >> -Alex
> >>
> >> On 12/3/13 4:05 PM, "David Coleman" <da...@hotmail.com>
> >>wrote:
> >>
> >> >I do agree with your numbers, (how could I not - they are spot on).
> >>The
> >> >primary issue is that WE host the rsl or the static link difference.
> >>and
> >> >the static link difference affects the size of our modules too. So
> >>it's
> >> >100% more for modules, and since we have 7.8 MB of modules (18
> >>different
> >> >popups each with animations/hd graphics etc), then we are talking about
> >> >static linking costing a lot more.
> >> >
> >> >If i can customize an RSL to service all 18 modules and the main app
> >>and
> >> >only have to distribute one file, that is even better for a new user
> >>than
> >> >the Adobe RSL's... ok we have to pay for the CDN costs... but it's less
> >> >than an extra 7.8 MB of static links for all our modules.
> >> >
> >> >Harbs pointed out the exact reason RSL is so critical to our use case.
> >> >Modules are doubled.
> >> >
> >> >Now, if the modules could only statically link what is lacking in the
> >> >static links of the main application, with out optimizing them and
> >> >pushing all the embedded assets to the main application... kinda like a
> >> >"half-optimized" module, then static link could really work for us.
> >>but
> >> >as long as an optimized module will push all the assets into the main
> >> >app, i can't optimize them to share the static links. so they need
> >>their
> >> >own static links...
> >> >
> >> >Maybe this is something that can work!
> >> >
> >> >how can i optimize a module to share the static links of the main app
> >> >without pushing all the embedded assets in the module to the main app?
> >> >does mxmlc include a metatag to exclude a class (embedded asset) from
> >> >module optimization? so it would stay in the module while i optimize
> >>it
> >> >for the main app, and then only have to statically link the few bits
> >>and
> >> >pieces that are lacking in each.
> >> >
> >> >> From: aharui@adobe.com
> >> >> To: dev@flex.apache.org
> >> >> Date: Tue, 3 Dec 2013 15:51:44 -0800
> >> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >> >>
> >> >> OK, so let me make sure I understand:
> >> >>
> >> >> For first time users, they have to download 3MB of Assets and the
> >>600K
> >> >>SWF
> >> >> and hopefully not the 1.4MB's of framework RSLs.
> >> >> For returning users, 3MB Assets and 600K SWF is hopefully in the
> >>browser
> >> >> cache.
> >> >>
> >> >> If you switch to Apache Flex:
> >> >> First-time users will have to download either
> >> >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
> >> >> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
> >> >>
> >> >> So, Apache Flex statically linked is another 600K and represents an
> >> >> additional 12% in download time.
> >> >>
> >> >> I don't know what the RSL penetration is of Flex 4.5.1, but every day
> >> >> folks are buying new computers and there are fewer and fewer Flex
> >>4.5.1
> >> >> apps out there in the world so the probability your first-time
> >>customers
> >> >> will have those RSLs is diminishing. Over time, more and more of
> >>your
> >> >> customers will be downloading the 1.4MB of framework RSLs as well,
> >>and
> >> >>the
> >> >> statically linked solution will be the smaller download.
> >> >>
> >> >> Have you used ItDepends or a similar link-report analyzer to see how
> >> >>much
> >> >> of that 600K is Greensock, Tweener and other stuff?
> >> >>
> >> >> -Alex
> >> >>
> >> >> On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com>
> >> >>wrote:
> >> >>
> >> >> >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_007@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: aharui@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"
> >><da...@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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
Wow. I don't think it is supposed to do that. Please create a simple
test case and create a JIRA issue.
-Alex
On 12/3/13 5:53 PM, "David Coleman" <da...@hotmail.com> wrote:
>For instance i have an app in flash builder with a boat load of modules
>
>I set one of these modules to be optimized for MyApp.mxml
>
>the embedded images in MyOptimizedModule end up in MyApp.mxml.
>
>The good thing is that MyApp and MyOptimizedModule can now be statically
>linked w/o doubling its size. the bad thing is that now I have defeated
>the purpose of putting my assets in the module.
>
>can I optimize a module for MyApp without all of its embedded assets
>ending up in the optimization target?
>
>It is my understanding that optimizing a module for a specific
>application ends up removing all embedded assets from the module and
>storing them in the application.
>
>If you want i can reproduce this in a few example projects and post it up
>on my git.
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Date: Tue, 3 Dec 2013 17:19:06 -0800
>> Subject: Re: SharedLibrary not works with SDK 4.11
>>
>> I don't understand the part about embedded assets. Can you provide more
>> details? The -externs option should let you keep any class out of any
>>SWF.
>>
>> You can create a shared code module or pack other classes needed by
>> modules onto extra frames of the main SWF.
>>
>> -Alex
>>
>> On 12/3/13 4:05 PM, "David Coleman" <da...@hotmail.com>
>>wrote:
>>
>> >I do agree with your numbers, (how could I not - they are spot on).
>>The
>> >primary issue is that WE host the rsl or the static link difference.
>>and
>> >the static link difference affects the size of our modules too. So
>>it's
>> >100% more for modules, and since we have 7.8 MB of modules (18
>>different
>> >popups each with animations/hd graphics etc), then we are talking about
>> >static linking costing a lot more.
>> >
>> >If i can customize an RSL to service all 18 modules and the main app
>>and
>> >only have to distribute one file, that is even better for a new user
>>than
>> >the Adobe RSL's... ok we have to pay for the CDN costs... but it's less
>> >than an extra 7.8 MB of static links for all our modules.
>> >
>> >Harbs pointed out the exact reason RSL is so critical to our use case.
>> >Modules are doubled.
>> >
>> >Now, if the modules could only statically link what is lacking in the
>> >static links of the main application, with out optimizing them and
>> >pushing all the embedded assets to the main application... kinda like a
>> >"half-optimized" module, then static link could really work for us.
>>but
>> >as long as an optimized module will push all the assets into the main
>> >app, i can't optimize them to share the static links. so they need
>>their
>> >own static links...
>> >
>> >Maybe this is something that can work!
>> >
>> >how can i optimize a module to share the static links of the main app
>> >without pushing all the embedded assets in the module to the main app?
>> >does mxmlc include a metatag to exclude a class (embedded asset) from
>> >module optimization? so it would stay in the module while i optimize
>>it
>> >for the main app, and then only have to statically link the few bits
>>and
>> >pieces that are lacking in each.
>> >
>> >> From: aharui@adobe.com
>> >> To: dev@flex.apache.org
>> >> Date: Tue, 3 Dec 2013 15:51:44 -0800
>> >> Subject: Re: SharedLibrary not works with SDK 4.11
>> >>
>> >> OK, so let me make sure I understand:
>> >>
>> >> For first time users, they have to download 3MB of Assets and the
>>600K
>> >>SWF
>> >> and hopefully not the 1.4MB's of framework RSLs.
>> >> For returning users, 3MB Assets and 600K SWF is hopefully in the
>>browser
>> >> cache.
>> >>
>> >> If you switch to Apache Flex:
>> >> First-time users will have to download either
>> >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
>> >> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
>> >>
>> >> So, Apache Flex statically linked is another 600K and represents an
>> >> additional 12% in download time.
>> >>
>> >> I don't know what the RSL penetration is of Flex 4.5.1, but every day
>> >> folks are buying new computers and there are fewer and fewer Flex
>>4.5.1
>> >> apps out there in the world so the probability your first-time
>>customers
>> >> will have those RSLs is diminishing. Over time, more and more of
>>your
>> >> customers will be downloading the 1.4MB of framework RSLs as well,
>>and
>> >>the
>> >> statically linked solution will be the smaller download.
>> >>
>> >> Have you used ItDepends or a similar link-report analyzer to see how
>> >>much
>> >> of that 600K is Greensock, Tweener and other stuff?
>> >>
>> >> -Alex
>> >>
>> >> On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com>
>> >>wrote:
>> >>
>> >> >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_007@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: aharui@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"
>><da...@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
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
For instance i have an app in flash builder with a boat load of modules
I set one of these modules to be optimized for MyApp.mxml
the embedded images in MyOptimizedModule end up in MyApp.mxml.
The good thing is that MyApp and MyOptimizedModule can now be statically linked w/o doubling its size. the bad thing is that now I have defeated the purpose of putting my assets in the module.
can I optimize a module for MyApp without all of its embedded assets ending up in the optimization target?
It is my understanding that optimizing a module for a specific application ends up removing all embedded assets from the module and storing them in the application.
If you want i can reproduce this in a few example projects and post it up on my git.
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Tue, 3 Dec 2013 17:19:06 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> I don't understand the part about embedded assets. Can you provide more
> details? The -externs option should let you keep any class out of any SWF.
>
> You can create a shared code module or pack other classes needed by
> modules onto extra frames of the main SWF.
>
> -Alex
>
> On 12/3/13 4:05 PM, "David Coleman" <da...@hotmail.com> wrote:
>
> >I do agree with your numbers, (how could I not - they are spot on). The
> >primary issue is that WE host the rsl or the static link difference. and
> >the static link difference affects the size of our modules too. So it's
> >100% more for modules, and since we have 7.8 MB of modules (18 different
> >popups each with animations/hd graphics etc), then we are talking about
> >static linking costing a lot more.
> >
> >If i can customize an RSL to service all 18 modules and the main app and
> >only have to distribute one file, that is even better for a new user than
> >the Adobe RSL's... ok we have to pay for the CDN costs... but it's less
> >than an extra 7.8 MB of static links for all our modules.
> >
> >Harbs pointed out the exact reason RSL is so critical to our use case.
> >Modules are doubled.
> >
> >Now, if the modules could only statically link what is lacking in the
> >static links of the main application, with out optimizing them and
> >pushing all the embedded assets to the main application... kinda like a
> >"half-optimized" module, then static link could really work for us. but
> >as long as an optimized module will push all the assets into the main
> >app, i can't optimize them to share the static links. so they need their
> >own static links...
> >
> >Maybe this is something that can work!
> >
> >how can i optimize a module to share the static links of the main app
> >without pushing all the embedded assets in the module to the main app?
> >does mxmlc include a metatag to exclude a class (embedded asset) from
> >module optimization? so it would stay in the module while i optimize it
> >for the main app, and then only have to statically link the few bits and
> >pieces that are lacking in each.
> >
> >> From: aharui@adobe.com
> >> To: dev@flex.apache.org
> >> Date: Tue, 3 Dec 2013 15:51:44 -0800
> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >>
> >> OK, so let me make sure I understand:
> >>
> >> For first time users, they have to download 3MB of Assets and the 600K
> >>SWF
> >> and hopefully not the 1.4MB's of framework RSLs.
> >> For returning users, 3MB Assets and 600K SWF is hopefully in the browser
> >> cache.
> >>
> >> If you switch to Apache Flex:
> >> First-time users will have to download either
> >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
> >> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
> >>
> >> So, Apache Flex statically linked is another 600K and represents an
> >> additional 12% in download time.
> >>
> >> I don't know what the RSL penetration is of Flex 4.5.1, but every day
> >> folks are buying new computers and there are fewer and fewer Flex 4.5.1
> >> apps out there in the world so the probability your first-time customers
> >> will have those RSLs is diminishing. Over time, more and more of your
> >> customers will be downloading the 1.4MB of framework RSLs as well, and
> >>the
> >> statically linked solution will be the smaller download.
> >>
> >> Have you used ItDepends or a similar link-report analyzer to see how
> >>much
> >> of that 600K is Greensock, Tweener and other stuff?
> >>
> >> -Alex
> >>
> >> On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com>
> >>wrote:
> >>
> >> >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_007@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: aharui@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" <da...@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
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
I don't understand the part about embedded assets. Can you provide more
details? The -externs option should let you keep any class out of any SWF.
You can create a shared code module or pack other classes needed by
modules onto extra frames of the main SWF.
-Alex
On 12/3/13 4:05 PM, "David Coleman" <da...@hotmail.com> wrote:
>I do agree with your numbers, (how could I not - they are spot on). The
>primary issue is that WE host the rsl or the static link difference. and
>the static link difference affects the size of our modules too. So it's
>100% more for modules, and since we have 7.8 MB of modules (18 different
>popups each with animations/hd graphics etc), then we are talking about
>static linking costing a lot more.
>
>If i can customize an RSL to service all 18 modules and the main app and
>only have to distribute one file, that is even better for a new user than
>the Adobe RSL's... ok we have to pay for the CDN costs... but it's less
>than an extra 7.8 MB of static links for all our modules.
>
>Harbs pointed out the exact reason RSL is so critical to our use case.
>Modules are doubled.
>
>Now, if the modules could only statically link what is lacking in the
>static links of the main application, with out optimizing them and
>pushing all the embedded assets to the main application... kinda like a
>"half-optimized" module, then static link could really work for us. but
>as long as an optimized module will push all the assets into the main
>app, i can't optimize them to share the static links. so they need their
>own static links...
>
>Maybe this is something that can work!
>
>how can i optimize a module to share the static links of the main app
>without pushing all the embedded assets in the module to the main app?
>does mxmlc include a metatag to exclude a class (embedded asset) from
>module optimization? so it would stay in the module while i optimize it
>for the main app, and then only have to statically link the few bits and
>pieces that are lacking in each.
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Date: Tue, 3 Dec 2013 15:51:44 -0800
>> Subject: Re: SharedLibrary not works with SDK 4.11
>>
>> OK, so let me make sure I understand:
>>
>> For first time users, they have to download 3MB of Assets and the 600K
>>SWF
>> and hopefully not the 1.4MB's of framework RSLs.
>> For returning users, 3MB Assets and 600K SWF is hopefully in the browser
>> cache.
>>
>> If you switch to Apache Flex:
>> First-time users will have to download either
>> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
>> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
>>
>> So, Apache Flex statically linked is another 600K and represents an
>> additional 12% in download time.
>>
>> I don't know what the RSL penetration is of Flex 4.5.1, but every day
>> folks are buying new computers and there are fewer and fewer Flex 4.5.1
>> apps out there in the world so the probability your first-time customers
>> will have those RSLs is diminishing. Over time, more and more of your
>> customers will be downloading the 1.4MB of framework RSLs as well, and
>>the
>> statically linked solution will be the smaller download.
>>
>> Have you used ItDepends or a similar link-report analyzer to see how
>>much
>> of that 600K is Greensock, Tweener and other stuff?
>>
>> -Alex
>>
>> On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com>
>>wrote:
>>
>> >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_007@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: aharui@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" <da...@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
>> >> >
>> >>
>> >
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
I do agree with your numbers, (how could I not - they are spot on). The primary issue is that WE host the rsl or the static link difference. and the static link difference affects the size of our modules too. So it's 100% more for modules, and since we have 7.8 MB of modules (18 different popups each with animations/hd graphics etc), then we are talking about static linking costing a lot more.
If i can customize an RSL to service all 18 modules and the main app and only have to distribute one file, that is even better for a new user than the Adobe RSL's... ok we have to pay for the CDN costs... but it's less than an extra 7.8 MB of static links for all our modules.
Harbs pointed out the exact reason RSL is so critical to our use case. Modules are doubled.
Now, if the modules could only statically link what is lacking in the static links of the main application, with out optimizing them and pushing all the embedded assets to the main application... kinda like a "half-optimized" module, then static link could really work for us. but as long as an optimized module will push all the assets into the main app, i can't optimize them to share the static links. so they need their own static links...
Maybe this is something that can work!
how can i optimize a module to share the static links of the main app without pushing all the embedded assets in the module to the main app? does mxmlc include a metatag to exclude a class (embedded asset) from module optimization? so it would stay in the module while i optimize it for the main app, and then only have to statically link the few bits and pieces that are lacking in each.
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Tue, 3 Dec 2013 15:51:44 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> OK, so let me make sure I understand:
>
> For first time users, they have to download 3MB of Assets and the 600K SWF
> and hopefully not the 1.4MB's of framework RSLs.
> For returning users, 3MB Assets and 600K SWF is hopefully in the browser
> cache.
>
> If you switch to Apache Flex:
> First-time users will have to download either
> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
> 2) 3MB of Assets and 1.2MB of SWF if you statically link.
>
> So, Apache Flex statically linked is another 600K and represents an
> additional 12% in download time.
>
> I don't know what the RSL penetration is of Flex 4.5.1, but every day
> folks are buying new computers and there are fewer and fewer Flex 4.5.1
> apps out there in the world so the probability your first-time customers
> will have those RSLs is diminishing. Over time, more and more of your
> customers will be downloading the 1.4MB of framework RSLs as well, and the
> statically linked solution will be the smaller download.
>
> Have you used ItDepends or a similar link-report analyzer to see how much
> of that 600K is Greensock, Tweener and other stuff?
>
> -Alex
>
> On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com> wrote:
>
> >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_007@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: aharui@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" <da...@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
> >> >
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
OK, so let me make sure I understand:
For first time users, they have to download 3MB of Assets and the 600K SWF
and hopefully not the 1.4MB's of framework RSLs.
For returning users, 3MB Assets and 600K SWF is hopefully in the browser
cache.
If you switch to Apache Flex:
First-time users will have to download either
1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN.
2) 3MB of Assets and 1.2MB of SWF if you statically link.
So, Apache Flex statically linked is another 600K and represents an
additional 12% in download time.
I don't know what the RSL penetration is of Flex 4.5.1, but every day
folks are buying new computers and there are fewer and fewer Flex 4.5.1
apps out there in the world so the probability your first-time customers
will have those RSLs is diminishing. Over time, more and more of your
customers will be downloading the 1.4MB of framework RSLs as well, and the
statically linked solution will be the smaller download.
Have you used ItDepends or a similar link-report analyzer to see how much
of that 600K is Greensock, Tweener and other stuff?
-Alex
On 12/3/13 3:11 PM, "David Coleman" <da...@hotmail.com> wrote:
>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_007@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: aharui@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" <da...@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
>> >
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
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_007@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: aharui@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" <da...@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
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
OK, I didn't mean to include the asset module, but for all the code
involved which you are currently pulling from the framework RSLs and then
adding your own (plus Greensock and Tweener), how will making a single
custom RSLs that may or may not be in the browser cache be better than a
single SWF that contains all of the code?
-Alex
On 12/3/13 2:56 PM, "David Coleman" <da...@hotmail.com> wrote:
>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: aharui@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" <da...@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
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
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: aharui@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" <da...@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
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
On 12/3/13 2:38 PM, "David Coleman" <da...@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
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
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.
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Tue, 3 Dec 2013 14:27:56 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> Apache Flex SDKs don't have signed RSLs that get separately cached by the
> Flash Player. Sure you can make your own RSLs and somehow hope it doesn't
> get booted from the browser cache, but I don't know why it would stay in
> the cache longer than a statically linked SWF.
>
> If you do turn on RSLs in Apache Flex SDKs, it should be smart about which
> RSLs get loaded and only load the ones you need and not "all" of them.
>
> Modules should not increase in size if statically linked unless they are
> using classes not used by the main app. And you can build shared code
> modules for your modules if needed.
>
> So, when considering Apache Flex, first realize that you must use the
> browser cache. My logic says, if you're going to use the browser cache,
> then RSLs won't help you (it would help if you are loading multiple
> applications from the same domain), so statically link your main SWF and
> then optimize it. If you were to use RSLs and the cache is missed then
> your total download would be much more than when statically linked, and if
> your one main SWF is in the cache, the fact that it is 600K bigger because
> it is statically linked shouldn't affect startup that much, if at all.
>
> Then, if you have one main SWF that is 500K of your own code, I'm still
> curious because that sounds like a lot to me. I haven't used FaceBook's
> libraries: how big is their "Hello World" app?
>
> And then, if a test of 500K+RSLs when all cached and a cached 1.1MB single
> SWF startup is the same, then you're back to optimizing startup.
>
> Of course, I could be missing something.
> -Alex
>
>
> On 12/3/13 12:52 PM, "David Coleman" <da...@hotmail.com> wrote:
>
> >You are right. using static framework linkage balloons the modules
> >beyond usefulness, easily double as you say, and sometimes more.
> >
> >Ideally, there would be a way for me to build a special optimized single
> >file RSL, and use a third party software such as Kindi SecureSWF and sign
> >it with my own certificate, and then include in that RSL all the core
> >classes needed for everything, app, modules, etc...
> >
> >certainly the overhead for a 3rd party certificate would be minimal
> >compared to the cost of linking the framework statically. And it would
> >be nice to trim down the framework to the bare essentials.
> >
> >If i could hack the RSLs in this way then I could propose Apache Flex as
> >being more secure and lower weight than a 4.5.1 sdk solution. Sure I
> >would need to religiously maintain the contents of the "FlexCore.swf"
> >RSL, but that's no big deal. perhaps i could even write some nifty tool
> >that uses ant that scans all the unique classes used in the various
> >link-report.xml's from the app and modules and then auto package this RSL
> >at build time...
> >
> >I'm fully aware that this would be challenging... but I'm just trying to
> >think of a way to be able to take our app into the future using Apache
> >Flex. I don't want to be locked into 4.5.1 for the next 6 or more years
> >of our application's projected life. That's the lazy way out.
> >
> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >> From: harbs.lists@gmail.com
> >> Date: Tue, 3 Dec 2013 22:12:00 +0200
> >> To: dev@flex.apache.org
> >>
> >> My educated guess on the size of such an app without using RSLs
> >>(depending on exactly which classes you're using) is about double your
> >>current size. That's still manageable. You can still use modules as you
> >>do today. Of course an issue is going to be all the modules. Every
> >>module gets bigger without using RSLs.
> >>
> >> Have you tried compiling without RSLs to see the actual difference in
> >>size?
> >>
> >> Harbs
> >>
> >> On Dec 3, 2013, at 4:41 PM, David Coleman wrote:
> >>
> >> >
> >>http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmark
> >>s&count=18&fb_bmpos=3_18
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > the main file (for the upcoming version) is 566k, currently it is
> >> > slightly over 600K, the assets are ~3 mb and i have implemented most
> >> > popups as external modules, to ensure that they load from cdn only
> >>one
> >> > time per session.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > The main application is a spark application. I use only simple
> >>objects,
> >> > Group, List etc... nothing uber fancy. Most of the heavy lifting is
> >> > done with AS3 for speed.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > We have a very large number of users. I can't statically link the
> >>libs
> >> > because ppl expect the blinding fast load that I have achieved. 566K
> >> > loads in the blink of an eye on even mediocre systems/connections.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Personally I would prefer to statically link the framework because
> >>RSL's
> >> > are yet another hit the browser has to make, but we need the users to
> >> > get into the game and play as fast as possible. I have maintained
> >>the
> >> > fastest load in our category on facebook for
> >> > nearly a year now. :) I intend/need to keep it that way.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > so your short answer is "a very big, yet very, very SMALL and
> >>optimized
> >> > facebook app" which is exactly why i have to use them :)
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Any way around this limitation would open the door for me to promote
> >>and
> >> > fast-track the adoption of Apache Flex. I need small and I need
> >>fast.
> >> > The rest is academic. Once I have the tools, I'll make it happen,
> >>and
> >> > we will migrate to Apache Flex. Our target
> >> > Flash Player version is 10.3 for maximum penetration.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > If there is any glimmer of hope to accomplish this... tell me, and
> >>let me know how I can help.
> >> >
> >> >> From: aharui@adobe.com
> >> >> To: dev@flex.apache.org
> >> >> Date: Mon, 2 Dec 2013 11:22:26 -0800
> >> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >> >>
> >> >>
> >> >>
> >> >> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com>
> >>wrote:
> >> >>
> >> >>> Having not tried this solution myself, this is pure speculation...
> >>but
> >> >>> couldn't local storage store this? set domain to be "*" and
> >>retrieve it
> >> >>> from the public svn repo. if not present the RSL manager can load
> >>it up
> >> >>> and in this way we can sign it with our own Cert and validate that
> >>cert
> >> >>> independent of Adobe? Would this be workable?
> >> >> I think you'd hit local storage limits.
> >> >>
> >> >>> RSL's are the only reason that I hesitate to migrate our Facebook
> >>app to
> >> >>> apache. it will kill our CDN.
> >> >>>
> >> >> Just curious: Have you actually measured the difference without
> >>RSLs? How
> >> >> big a Facebook app is this?
> >> >>
> >> >> -Alex
> >> >>
> >> >
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
On 12/3/13 2:31 PM, "David Coleman" <da...@hotmail.com> wrote:
>The point is that WE have to host that extra file.
>
>Therefore I would want to eliminate the need for multiple RSL's and
>consolidate them into a single smaller optimized RSL with only the
>necessary classes needed for my app, with their dependencies.
OK, but my logic says that this custom RSL (because it won't be put in the
special Flash Player cache) is just as likely to be missing from the
browser cache as a single monolithic SWF. So maybe you should just build
one monolithic SWF. Did you know you can package Flex Modules onto extra
frames of a SWF? It makes your build process take longer, but then there
isn't a hit per module. It might be one big SWF though.
-Alex
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
The point is that WE have to host that extra file.
Therefore I would want to eliminate the need for multiple RSL's and consolidate them into a single smaller optimized RSL with only the necessary classes needed for my app, with their dependencies.
This would eliminate the need for every user generating 5n 301 hits against our CDN, where n==1+number of modules.
When you are talking about an app with 1.5-2M MAU the cost of 5n 301's is considerable, and reducing that to n 301's is a significant benefit.
> Subject: Re: SharedLibrary not works with SDK 4.11
> From: justin@classsoftware.com
> Date: Wed, 4 Dec 2013 08:27:52 +1100
> To: dev@flex.apache.org
>
> Hi,
>
> Perhaps I missing the point but you can use framework RSLs with Apache Flex, however they will be cached by the users browser and may still be useful and give some advantages for an application that is used frequently, has high usage or with multiple application from the same domain. It's not going to be as good as the framework being cached by teh flash player but woudl still have some benefit. Can you do some A/B testing and see what the actual results would be for a small part of your users?
>
> There's not much point in signing RSLs as it was a Flash Player feature that signed the RSLs not a Flex SDK feature, the Flash Player would need to change in order to cache the Apache or user signed RSL and that's probably not possible.
>
> Thanks,
> Justin
Re: SharedLibrary not works with SDK 4.11
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Perhaps I missing the point but you can use framework RSLs with Apache Flex, however they will be cached by the users browser and may still be useful and give some advantages for an application that is used frequently, has high usage or with multiple application from the same domain. It's not going to be as good as the framework being cached by teh flash player but woudl still have some benefit. Can you do some A/B testing and see what the actual results would be for a small part of your users?
There's not much point in signing RSLs as it was a Flash Player feature that signed the RSLs not a Flex SDK feature, the Flash Player would need to change in order to cache the Apache or user signed RSL and that's probably not possible.
Thanks,
Justin
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
Apache Flex SDKs don't have signed RSLs that get separately cached by the
Flash Player. Sure you can make your own RSLs and somehow hope it doesn't
get booted from the browser cache, but I don't know why it would stay in
the cache longer than a statically linked SWF.
If you do turn on RSLs in Apache Flex SDKs, it should be smart about which
RSLs get loaded and only load the ones you need and not "all" of them.
Modules should not increase in size if statically linked unless they are
using classes not used by the main app. And you can build shared code
modules for your modules if needed.
So, when considering Apache Flex, first realize that you must use the
browser cache. My logic says, if you're going to use the browser cache,
then RSLs won't help you (it would help if you are loading multiple
applications from the same domain), so statically link your main SWF and
then optimize it. If you were to use RSLs and the cache is missed then
your total download would be much more than when statically linked, and if
your one main SWF is in the cache, the fact that it is 600K bigger because
it is statically linked shouldn't affect startup that much, if at all.
Then, if you have one main SWF that is 500K of your own code, I'm still
curious because that sounds like a lot to me. I haven't used FaceBook's
libraries: how big is their "Hello World" app?
And then, if a test of 500K+RSLs when all cached and a cached 1.1MB single
SWF startup is the same, then you're back to optimizing startup.
Of course, I could be missing something.
-Alex
On 12/3/13 12:52 PM, "David Coleman" <da...@hotmail.com> wrote:
>You are right. using static framework linkage balloons the modules
>beyond usefulness, easily double as you say, and sometimes more.
>
>Ideally, there would be a way for me to build a special optimized single
>file RSL, and use a third party software such as Kindi SecureSWF and sign
>it with my own certificate, and then include in that RSL all the core
>classes needed for everything, app, modules, etc...
>
>certainly the overhead for a 3rd party certificate would be minimal
>compared to the cost of linking the framework statically. And it would
>be nice to trim down the framework to the bare essentials.
>
>If i could hack the RSLs in this way then I could propose Apache Flex as
>being more secure and lower weight than a 4.5.1 sdk solution. Sure I
>would need to religiously maintain the contents of the "FlexCore.swf"
>RSL, but that's no big deal. perhaps i could even write some nifty tool
>that uses ant that scans all the unique classes used in the various
>link-report.xml's from the app and modules and then auto package this RSL
>at build time...
>
>I'm fully aware that this would be challenging... but I'm just trying to
>think of a way to be able to take our app into the future using Apache
>Flex. I don't want to be locked into 4.5.1 for the next 6 or more years
>of our application's projected life. That's the lazy way out.
>
>> Subject: Re: SharedLibrary not works with SDK 4.11
>> From: harbs.lists@gmail.com
>> Date: Tue, 3 Dec 2013 22:12:00 +0200
>> To: dev@flex.apache.org
>>
>> My educated guess on the size of such an app without using RSLs
>>(depending on exactly which classes you're using) is about double your
>>current size. That's still manageable. You can still use modules as you
>>do today. Of course an issue is going to be all the modules. Every
>>module gets bigger without using RSLs.
>>
>> Have you tried compiling without RSLs to see the actual difference in
>>size?
>>
>> Harbs
>>
>> On Dec 3, 2013, at 4:41 PM, David Coleman wrote:
>>
>> >
>>http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmark
>>s&count=18&fb_bmpos=3_18
>> >
>> >
>> >
>> >
>> >
>> > the main file (for the upcoming version) is 566k, currently it is
>> > slightly over 600K, the assets are ~3 mb and i have implemented most
>> > popups as external modules, to ensure that they load from cdn only
>>one
>> > time per session.
>> >
>> >
>> >
>> >
>> >
>> > The main application is a spark application. I use only simple
>>objects,
>> > Group, List etc... nothing uber fancy. Most of the heavy lifting is
>> > done with AS3 for speed.
>> >
>> >
>> >
>> >
>> >
>> > We have a very large number of users. I can't statically link the
>>libs
>> > because ppl expect the blinding fast load that I have achieved. 566K
>> > loads in the blink of an eye on even mediocre systems/connections.
>> >
>> >
>> >
>> >
>> >
>> > Personally I would prefer to statically link the framework because
>>RSL's
>> > are yet another hit the browser has to make, but we need the users to
>> > get into the game and play as fast as possible. I have maintained
>>the
>> > fastest load in our category on facebook for
>> > nearly a year now. :) I intend/need to keep it that way.
>> >
>> >
>> >
>> >
>> >
>> > so your short answer is "a very big, yet very, very SMALL and
>>optimized
>> > facebook app" which is exactly why i have to use them :)
>> >
>> >
>> >
>> >
>> >
>> > Any way around this limitation would open the door for me to promote
>>and
>> > fast-track the adoption of Apache Flex. I need small and I need
>>fast.
>> > The rest is academic. Once I have the tools, I'll make it happen,
>>and
>> > we will migrate to Apache Flex. Our target
>> > Flash Player version is 10.3 for maximum penetration.
>> >
>> >
>> >
>> >
>> >
>> > If there is any glimmer of hope to accomplish this... tell me, and
>>let me know how I can help.
>> >
>> >> From: aharui@adobe.com
>> >> To: dev@flex.apache.org
>> >> Date: Mon, 2 Dec 2013 11:22:26 -0800
>> >> Subject: Re: SharedLibrary not works with SDK 4.11
>> >>
>> >>
>> >>
>> >> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com>
>>wrote:
>> >>
>> >>> Having not tried this solution myself, this is pure speculation...
>>but
>> >>> couldn't local storage store this? set domain to be "*" and
>>retrieve it
>> >>> from the public svn repo. if not present the RSL manager can load
>>it up
>> >>> and in this way we can sign it with our own Cert and validate that
>>cert
>> >>> independent of Adobe? Would this be workable?
>> >> I think you'd hit local storage limits.
>> >>
>> >>> RSL's are the only reason that I hesitate to migrate our Facebook
>>app to
>> >>> apache. it will kill our CDN.
>> >>>
>> >> Just curious: Have you actually measured the difference without
>>RSLs? How
>> >> big a Facebook app is this?
>> >>
>> >> -Alex
>> >>
>> >
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
You are right. using static framework linkage balloons the modules beyond usefulness, easily double as you say, and sometimes more.
Ideally, there would be a way for me to build a special optimized single file RSL, and use a third party software such as Kindi SecureSWF and sign it with my own certificate, and then include in that RSL all the core classes needed for everything, app, modules, etc...
certainly the overhead for a 3rd party certificate would be minimal compared to the cost of linking the framework statically. And it would be nice to trim down the framework to the bare essentials.
If i could hack the RSLs in this way then I could propose Apache Flex as being more secure and lower weight than a 4.5.1 sdk solution. Sure I would need to religiously maintain the contents of the "FlexCore.swf" RSL, but that's no big deal. perhaps i could even write some nifty tool that uses ant that scans all the unique classes used in the various link-report.xml's from the app and modules and then auto package this RSL at build time...
I'm fully aware that this would be challenging... but I'm just trying to think of a way to be able to take our app into the future using Apache Flex. I don't want to be locked into 4.5.1 for the next 6 or more years of our application's projected life. That's the lazy way out.
> Subject: Re: SharedLibrary not works with SDK 4.11
> From: harbs.lists@gmail.com
> Date: Tue, 3 Dec 2013 22:12:00 +0200
> To: dev@flex.apache.org
>
> My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs.
>
> Have you tried compiling without RSLs to see the actual difference in size?
>
> Harbs
>
> On Dec 3, 2013, at 4:41 PM, David Coleman wrote:
>
> > http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmarks&count=18&fb_bmpos=3_18
> >
> >
> >
> >
> >
> > the main file (for the upcoming version) is 566k, currently it is
> > slightly over 600K, the assets are ~3 mb and i have implemented most
> > popups as external modules, to ensure that they load from cdn only one
> > time per session.
> >
> >
> >
> >
> >
> > The main application is a spark application. I use only simple objects,
> > Group, List etc... nothing uber fancy. Most of the heavy lifting is
> > done with AS3 for speed.
> >
> >
> >
> >
> >
> > We have a very large number of users. I can't statically link the libs
> > because ppl expect the blinding fast load that I have achieved. 566K
> > loads in the blink of an eye on even mediocre systems/connections.
> >
> >
> >
> >
> >
> > Personally I would prefer to statically link the framework because RSL's
> > are yet another hit the browser has to make, but we need the users to
> > get into the game and play as fast as possible. I have maintained the
> > fastest load in our category on facebook for
> > nearly a year now. :) I intend/need to keep it that way.
> >
> >
> >
> >
> >
> > so your short answer is "a very big, yet very, very SMALL and optimized
> > facebook app" which is exactly why i have to use them :)
> >
> >
> >
> >
> >
> > Any way around this limitation would open the door for me to promote and
> > fast-track the adoption of Apache Flex. I need small and I need fast.
> > The rest is academic. Once I have the tools, I'll make it happen, and
> > we will migrate to Apache Flex. Our target
> > Flash Player version is 10.3 for maximum penetration.
> >
> >
> >
> >
> >
> > If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help.
> >
> >> From: aharui@adobe.com
> >> To: dev@flex.apache.org
> >> Date: Mon, 2 Dec 2013 11:22:26 -0800
> >> Subject: Re: SharedLibrary not works with SDK 4.11
> >>
> >>
> >>
> >> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com> wrote:
> >>
> >>> Having not tried this solution myself, this is pure speculation... but
> >>> couldn't local storage store this? set domain to be "*" and retrieve it
> >>> from the public svn repo. if not present the RSL manager can load it up
> >>> and in this way we can sign it with our own Cert and validate that cert
> >>> independent of Adobe? Would this be workable?
> >> I think you'd hit local storage limits.
> >>
> >>> RSL's are the only reason that I hesitate to migrate our Facebook app to
> >>> apache. it will kill our CDN.
> >>>
> >> Just curious: Have you actually measured the difference without RSLs? How
> >> big a Facebook app is this?
> >>
> >> -Alex
> >>
> >
>
Re: SharedLibrary not works with SDK 4.11
Posted by Harbs <ha...@gmail.com>.
My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs.
Have you tried compiling without RSLs to see the actual difference in size?
Harbs
On Dec 3, 2013, at 4:41 PM, David Coleman wrote:
> http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmarks&count=18&fb_bmpos=3_18
>
>
>
>
>
> the main file (for the upcoming version) is 566k, currently it is
> slightly over 600K, the assets are ~3 mb and i have implemented most
> popups as external modules, to ensure that they load from cdn only one
> time per session.
>
>
>
>
>
> The main application is a spark application. I use only simple objects,
> Group, List etc... nothing uber fancy. Most of the heavy lifting is
> done with AS3 for speed.
>
>
>
>
>
> We have a very large number of users. I can't statically link the libs
> because ppl expect the blinding fast load that I have achieved. 566K
> loads in the blink of an eye on even mediocre systems/connections.
>
>
>
>
>
> Personally I would prefer to statically link the framework because RSL's
> are yet another hit the browser has to make, but we need the users to
> get into the game and play as fast as possible. I have maintained the
> fastest load in our category on facebook for
> nearly a year now. :) I intend/need to keep it that way.
>
>
>
>
>
> so your short answer is "a very big, yet very, very SMALL and optimized
> facebook app" which is exactly why i have to use them :)
>
>
>
>
>
> Any way around this limitation would open the door for me to promote and
> fast-track the adoption of Apache Flex. I need small and I need fast.
> The rest is academic. Once I have the tools, I'll make it happen, and
> we will migrate to Apache Flex. Our target
> Flash Player version is 10.3 for maximum penetration.
>
>
>
>
>
> If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help.
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Date: Mon, 2 Dec 2013 11:22:26 -0800
>> Subject: Re: SharedLibrary not works with SDK 4.11
>>
>>
>>
>> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com> wrote:
>>
>>> Having not tried this solution myself, this is pure speculation... but
>>> couldn't local storage store this? set domain to be "*" and retrieve it
>>> from the public svn repo. if not present the RSL manager can load it up
>>> and in this way we can sign it with our own Cert and validate that cert
>>> independent of Adobe? Would this be workable?
>> I think you'd hit local storage limits.
>>
>>> RSL's are the only reason that I hesitate to migrate our Facebook app to
>>> apache. it will kill our CDN.
>>>
>> Just curious: Have you actually measured the difference without RSLs? How
>> big a Facebook app is this?
>>
>> -Alex
>>
>
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
Hi David,
So you are saying that there is 566K in non-Flex code and assets to
generate the first screen (after the preloader)? How much of that is
assets and how much is code? And what Flex classes are used in that first
screen? Usually, folks take a second after seeing the first screen before
they act on it, and you can often do a bunch of downloading and
initializing in that time. If you move everything not required for the
first screen to a late-loaded module, you might find that the total
framework load goes down and static linking becomes possible. That
wouldn't be true for some app that has a DataGrid on the first screen, but
I don't think I'm seeing heavyweight components on your first screen.
-Alex
On 12/3/13 6:41 AM, "David Coleman" <da...@hotmail.com> wrote:
>http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmarks
>&count=18&fb_bmpos=3_18
>
>
>
>
>
>the main file (for the upcoming version) is 566k, currently it is
>slightly over 600K, the assets are ~3 mb and i have implemented most
>popups as external modules, to ensure that they load from cdn only one
>time per session.
>
>
>
>
>
>The main application is a spark application. I use only simple objects,
> Group, List etc... nothing uber fancy. Most of the heavy lifting is
>done with AS3 for speed.
>
>
>
>
>
>We have a very large number of users. I can't statically link the libs
>because ppl expect the blinding fast load that I have achieved. 566K
>loads in the blink of an eye on even mediocre systems/connections.
>
>
>
>
>
>Personally I would prefer to statically link the framework because RSL's
> are yet another hit the browser has to make, but we need the users to
>get into the game and play as fast as possible. I have maintained the
>fastest load in our category on facebook for
>nearly a year now. :) I intend/need to keep it that way.
>
>
>
>
>
>so your short answer is "a very big, yet very, very SMALL and optimized
>facebook app" which is exactly why i have to use them :)
>
>
>
>
>
>Any way around this limitation would open the door for me to promote and
> fast-track the adoption of Apache Flex. I need small and I need fast.
> The rest is academic. Once I have the tools, I'll make it happen, and
>we will migrate to Apache Flex. Our target
>Flash Player version is 10.3 for maximum penetration.
>
>
>
>
>
>If there is any glimmer of hope to accomplish this... tell me, and let
>me know how I can help.
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Date: Mon, 2 Dec 2013 11:22:26 -0800
>> Subject: Re: SharedLibrary not works with SDK 4.11
>>
>>
>>
>> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com>
>>wrote:
>>
>> >Having not tried this solution myself, this is pure speculation... but
>> >couldn't local storage store this? set domain to be "*" and retrieve
>>it
>> >from the public svn repo. if not present the RSL manager can load it
>>up
>> >and in this way we can sign it with our own Cert and validate that cert
>> >independent of Adobe? Would this be workable?
>> I think you'd hit local storage limits.
>>
>> >RSL's are the only reason that I hesitate to migrate our Facebook app
>>to
>> >apache. it will kill our CDN.
>> >
>> Just curious: Have you actually measured the difference without RSLs?
>>How
>> big a Facebook app is this?
>>
>> -Alex
>>
>
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
http://apps.facebook.com/houseoffun/?fb_source=bookmark_apps&ref=bookmarks&count=18&fb_bmpos=3_18
the main file (for the upcoming version) is 566k, currently it is
slightly over 600K, the assets are ~3 mb and i have implemented most
popups as external modules, to ensure that they load from cdn only one
time per session.
The main application is a spark application. I use only simple objects,
Group, List etc... nothing uber fancy. Most of the heavy lifting is
done with AS3 for speed.
We have a very large number of users. I can't statically link the libs
because ppl expect the blinding fast load that I have achieved. 566K
loads in the blink of an eye on even mediocre systems/connections.
Personally I would prefer to statically link the framework because RSL's
are yet another hit the browser has to make, but we need the users to
get into the game and play as fast as possible. I have maintained the
fastest load in our category on facebook for
nearly a year now. :) I intend/need to keep it that way.
so your short answer is "a very big, yet very, very SMALL and optimized
facebook app" which is exactly why i have to use them :)
Any way around this limitation would open the door for me to promote and
fast-track the adoption of Apache Flex. I need small and I need fast.
The rest is academic. Once I have the tools, I'll make it happen, and
we will migrate to Apache Flex. Our target
Flash Player version is 10.3 for maximum penetration.
If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help.
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Date: Mon, 2 Dec 2013 11:22:26 -0800
> Subject: Re: SharedLibrary not works with SDK 4.11
>
>
>
> On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com> wrote:
>
> >Having not tried this solution myself, this is pure speculation... but
> >couldn't local storage store this? set domain to be "*" and retrieve it
> >from the public svn repo. if not present the RSL manager can load it up
> >and in this way we can sign it with our own Cert and validate that cert
> >independent of Adobe? Would this be workable?
> I think you'd hit local storage limits.
>
> >RSL's are the only reason that I hesitate to migrate our Facebook app to
> >apache. it will kill our CDN.
> >
> Just curious: Have you actually measured the difference without RSLs? How
> big a Facebook app is this?
>
> -Alex
>
RE: SharedLibrary not works with SDK 4.11
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Our RSL's are from the SDK we are actively using. Then we use custom flex-config files to add the "runtime-shared-library-path" nodes for the RSLs. This allows us to declare where on our servers the RSLs are. The 4.6 Adobe signed ones use a custom cache for flash that doesn't easily get wiped out. The new ones you make will end up in the users browser cache. Since all of our applications are on the same domain, we can have them share the cached RSLs.
Not sure how to go about trying to get it into the local store and then reference it later. The application would be still trying to reference it from the server and the client browser would just offer it up out of the browser cache.
On a side note, I haven't tried yet, but would love to host the RSLs from a separate server in the domain to balance out the network load a little.
-Mark
-----Original Message-----
From: David Coleman [mailto:david_coleman_007@hotmail.com]
Sent: Monday, December 02, 2013 1:14 PM
To: dev@flex.apache.org
Subject: RE: SharedLibrary not works with SDK 4.11
Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be "*" and retrieve it from the public svn repo. if not present the RSL manager can load it up and in this way we can sign it with our own Cert and validate that cert independent of Adobe? Would this be workable?
I've used local storage only for single sites before... but wouldn't it be possible to massage local storage to store something "global", like rsls?
Or in your case, Mark, you could maybe do something similar at the application level, storing them at least for your own set of applications under a base domain...
RSL's are the only reason that I hesitate to migrate our Facebook app to apache. it will kill our CDN.
Re: SharedLibrary not works with SDK 4.11
Posted by Alex Harui <ah...@adobe.com>.
On 12/2/13 10:13 AM, "David Coleman" <da...@hotmail.com> wrote:
>Having not tried this solution myself, this is pure speculation... but
>couldn't local storage store this? set domain to be "*" and retrieve it
>from the public svn repo. if not present the RSL manager can load it up
>and in this way we can sign it with our own Cert and validate that cert
>independent of Adobe? Would this be workable?
I think you'd hit local storage limits.
>RSL's are the only reason that I hesitate to migrate our Facebook app to
>apache. it will kill our CDN.
>
Just curious: Have you actually measured the difference without RSLs? How
big a Facebook app is this?
-Alex
RE: SharedLibrary not works with SDK 4.11
Posted by David Coleman <da...@hotmail.com>.
Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be "*" and retrieve it from the public svn repo. if not present the RSL manager can load it up and in this way we can sign it with our own Cert and validate that cert independent of Adobe? Would this be workable?
I've used local storage only for single sites before... but wouldn't it be possible to massage local storage to store something "global", like rsls?
Or in your case, Mark, you could maybe do something similar at the application level, storing them at least for your own set of applications under a base domain...
RSL's are the only reason that I hesitate to migrate our Facebook app to apache. it will kill our CDN.
> Subject: RE: SharedLibrary not works with SDK 4.11
> Date: Mon, 2 Dec 2013 11:53:17 -0500
> From: mark.kessler.ctr@usmc.mil
> To: dev@flex.apache.org
>
> Well they are not pointless if you host multiple applications from the same servers, but definitely degraded capabilities not being able to have a separate cache for them.
>
> -Mark
>
> -----Original Message-----
> From: Harbs [mailto:harbs.lists@gmail.com]
> Sent: Monday, December 02, 2013 10:11 AM
> To: dev@flex.apache.org
> Subject: Re: SharedLibrary not works with SDK 4.11
>
> RSLs are not enabled for Apache Flex. There have been many discussions on the topic. Basically, without Adobe's signatures, RSLs are more or less pointless.
>
> On Dec 2, 2013, at 5:05 PM, FRANKLIN GARZON wrote:
>
> > I have some problemas with SDK4.11 about the sahred library, please see this bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3674828 , ADOBE says is not for this product.
> > Who can help us?
> > Thanks.
> >
> >
> > Franklin Garzón
> >
> > *Lucha hasta alcanzar tus sueños*
> >
> >
> >
> >
>
RE: SharedLibrary not works with SDK 4.11
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Well they are not pointless if you host multiple applications from the same servers, but definitely degraded capabilities not being able to have a separate cache for them.
-Mark
-----Original Message-----
From: Harbs [mailto:harbs.lists@gmail.com]
Sent: Monday, December 02, 2013 10:11 AM
To: dev@flex.apache.org
Subject: Re: SharedLibrary not works with SDK 4.11
RSLs are not enabled for Apache Flex. There have been many discussions on the topic. Basically, without Adobe's signatures, RSLs are more or less pointless.
On Dec 2, 2013, at 5:05 PM, FRANKLIN GARZON wrote:
> I have some problemas with SDK4.11 about the sahred library, please see this bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3674828 , ADOBE says is not for this product.
> Who can help us?
> Thanks.
>
>
> Franklin Garzón
>
> *Lucha hasta alcanzar tus sueños*
>
>
>
>
Re: SharedLibrary not works with SDK 4.11
Posted by Harbs <ha...@gmail.com>.
RSLs are not enabled for Apache Flex. There have been many discussions on the topic. Basically, without Adobe's signatures, RSLs are more or less pointless.
On Dec 2, 2013, at 5:05 PM, FRANKLIN GARZON wrote:
> I have some problemas with SDK4.11 about the sahred library, please see this bug: https://bugbase.adobe.com/index.cfm?event=bug&id=3674828 , ADOBE says is not for this product.
> Who can help us?
> Thanks.
>
>
> Franklin Garzón
>
> *Lucha hasta alcanzar tus sueños*
>
>
>
>