Links reports help a lot. It reduces modules down noticeably. However you have a harder time doing incremental compiling. There are a few instances where it doesn't compile the latest code properly.
-----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Sunday, February 10, 2013 11:09 AM To: dev@flex.apache.org Subject: Re: RSLs and signing On 2/10/13 7:41 AM, "Harbs" <harbs.li...@gmail.com> wrote: > The numbers were for release. > > The debug size using RSLs is about 1 MB. > > I'm not really sure if modules can help. There are not many modular components > in the app. Maybe I can load the image browser as a module, but I don't know > how much of a difference that will make. There are a number of palettes that > might be candidates. I'll see what I can do on that front, but I don't have > high hopes. My bigger concern is really the Flex libs which have more bulk > than the whole app... Is there a good way of figuring out where the bulk is > coming from? Link-reports might help. I went to your demo page at: https://printui.com/web-to-print-demo-step-1.php The first screen just looks like buttons and an image loader to me. That shouldn't be that big. As soon as the image loads, I would request load of a module of other UI widgets and associated logic while the user is pondering what to do next. I don't know about the ethics of it, but since your landing pages are php, I'm not sure why you couldn't start pre-loading other SWFs after the page is displayed so more stuff is there if the user continues on. > > If I'm reading you right, the caching of swfs is actually more persistent than > the caching of unsigned RSLs. Right? RSLs and SWFs have the same caching rules in the browser. The issue is the probability of a cache-miss. The signed RSL cache in the player prevented cache-misses if the user had no browser cache or emptied the cache or had limits on cache size. > > On Feb 10, 2013, at 5:19 PM, Alex Harui wrote: > >> The only advantage to un-signed RSLs is if you serve more than one SWF that >> uses them from your domain. SWFs end up on disk in a browser cache (if >> there is one and within the limitations of that cache) so then there is a >> probability you won't have to download some code. >> >> Apache Flex will hopefully release often. The Framework RSLs were >> version-specific, so releasing often further lowers your chances of any >> benefit even if we did have a way to serve cross-domain RSLs. >> >> I suppose we could try to host RSLs at some known place, but browser cache >> limitations would still apply, and you'd want a custom domain name otherwise >> you'd expose yourself to cross-domain scripting. >> >> Are your SWF size numbers for release mode or debug mode? Using modules >> carefully can lower the size of the initial load. >> >> >> On 2/10/13 6:54 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> Okay. Like you said this sucks. >>> >>> I'm looking to moving from Flex 4.5 to 4.9 in the next few weeks. I just >>> changed my compile settings to merge instead of using RSLs and the app went >>> from a little over 600 KB to 1.4 MB. :-( >>> >>> I clearly have a lot of work to do removing dependency on a lot of classes >>> and >>> getting rid of dependency on mx components (I have a very few in use, but >>> the >>> ones that I'm using will be hard to replace with Spark.) >>> >>> I'm still not sure why Flash can't cache third party signed RSLs, but >>> there's >>> not much to be gained by kvetching about it. I doubt they'll add that as a >>> feature to FlashŠ >>> >>> Harbs >>> >>> On Feb 10, 2013, at 4:37 PM, Nicholas Kwiatkowski wrote: >>> >>>> When I say signed, I'm meaning signed by Adobe. There really is >>>> little benefit to sign an RSL with our certificates, as they are in the web >>>> of trust of the Flash Player. >>>> >>>> From what I've been told, unless it is signed by Adobe, it is not in >>>> the persistent cache, so it is not cached on disk, period. This is >>>> regardless of the domain that it is on. >>>> >>>> This came up VERY early on (maybe even at the Tech Summit -- I don't know, >>>> I wasn't there), and Adobe was pretty straight forward that this was going >>>> to be the case. Questions came up about having them sign it, but they did >>>> not want to dedicated the resources to do it. Looking back, it would have >>>> been a pain to have to submit our releases to Adobe for their complete >>>> review before we could do anything -- potentially holding back our releases >>>> weeks or months. >>>> >>>> It was seen as a majority of the Flex work was moving to mobile. On AIR >>>> with mobile, there is no concept of RSLs (everything is embedded within the >>>> final executable), so it was seen as less of an issue. >>>> >>>> -Nick >>>> >>>> On Sun, Feb 10, 2013 at 9:27 AM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>>> Bah! So they're totally useless. >>>>> >>>>> swfs are also cached by the browser for that session. Correct? >>>>> >>>>> Is there any logic to not caching RSLs for the domain that loaded them? >>>>> >>>>>> Only signed RSLs are cached on disk. >>>>> >>>>> Signed meaning signed by Adobe. Right? There's no way to sign a RSL with >>>>> an SSL or code signing certificate. Is there? >>>>> >>>>> On Feb 10, 2013, at 4:19 PM, Nicholas Kwiatkowski wrote: >>>>> >>>>>> They are downloaded once per domain, per session. If you visit domain >>>>>> x.comtwice in a session (as defined by your browser), then it will >>>>>> stay in >>>>>> memory. If you close your session (typically by closing your browser), >>>>>> then it will be cleared from memory. >>>>>> >>>>>> Only signed RSLs are cached on disk. >>>>>> >>>>>> -Nick >>>>>> >>>>>> On Sun, Feb 10, 2013 at 9:01 AM, Harbs <harbs.li...@gmail.com> wrote: >>>>>> >>>>>>> I apparently missed this. Yes. It does suck. Are RSLs reloaded every >>>>> time >>>>>>> for a specific domain, or is it just a cross-domain issue? >>>>>>> >>>>>>> If I use RSLs for Flex 4.9 and I update my main app, do the RSLs get >>>>>>> downloaded every time, or will the RSLs from my domain be reused? Is >>>>> there >>>>>>> any point in using RSLs at all? >>>>>>> >>>>>>> On Feb 10, 2013, at 3:56 PM, Nicholas Kwiatkowski wrote: >>>>>>> >>>>>>>> Adobe has (had?) a pretty good explanation on their Flash Whitepaper. >>>>> It >>>>>>>> boils down to this : >>>>>>>> - They are no longer in control of Flex >>>>>>>> - They are no longer doing security reviews of the source code >>>>>>>> - They have to sign the Flex package with their security certificate in >>>>>>>> order for it to be stored in the Flash RSL Cache >>>>>>>> - They won't sign it anymore because they would be responsible for any >>>>>>>> security issues that may come out of it. >>>>>>>> >>>>>>>> Yes, it sucks, but unfortunately, we have to live with it. >>>>>>>> >>>>>>>> -Nick >>>>>>>> >>>>>>>> On Sun, Feb 10, 2013 at 8:49 AM, christofer.d...@c-ware.de < >>>>>>>> christofer.d...@c-ware.de> wrote: >>>>>>>> >>>>>>>>> I have to admit, that I don't quite understand what the inability to >>>>>>>>> create signed rsls has to do with the usage of rsls themselves. >>>>>>>>> >>>>>>>>> The problem is that the Flashplayer is able to install rsls that are >>>>>>>>> signed by Adobe. Usually the Adobe FDK rsls were also available in >>>>>>> signed >>>>>>>>> versions (swz files). These were dynamically loaded the first time >>>>> they >>>>>>>>> were needed and installed by the Flashplayer. The second time the libs >>>>>>> were >>>>>>>>> needed the installed versions were used reducing the download time >>>>>>>>> dramatically. Now the problem is that Adobe won't sign Apache SWCs as >>>>>>> they >>>>>>>>> are no longer in charge of the libs code (Understandable). Giving >>>>>>> Apache a >>>>>>>>> key to be able to also create signed RSLs would eventually open >>>>> serious >>>>>>>>> security problems because a signed manipulated swz would be used by >>>>>>> every >>>>>>>>> other website using the same version of a given lib. >>>>>>>>> >>>>>>>>> Coming back to the RSLs ... The difference between a signed and an >>>>>>>>> unsigned RSL is just, that the unsigned rsl is loaded on every visit >>>>> of >>>>>>> a >>>>>>>>> user. As far as I know there is no other difference. So I don't quite >>>>>>>>> understand why the lack of availability of signed rsls should have any >>>>>>>>> effect on built applications and the default linking type. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>> Von: Harbs [mailto:harbs.li...@gmail.com] >>>>>>>>> Gesendet: Sonntag, 10. Februar 2013 14:19 >>>>>>>>> An: dev@flex.apache.org >>>>>>>>> Betreff: RSLs and signing >>>>>>>>> >>>>>>>>> I did not realize that Apache Flex does not use RSLs by default. >>>>>>>>> >>>>>>>>> What's the story with signing? Is that an issue with cross-domain >>>>>>>>> security? Is there any way to get an Apache signature approved for >>>>>>> Flash? >>>>>>>>> >>>>>>>>> Either way, I'd imagine I'd want RSLs for the simple reason that >>>>>>> updating >>>>>>>>> apps should result in a smaller download. >>>>>>>>> >>>>>>>>> Harbs >>>>>>>>> >>>>>>>>> On Feb 9, 2013, at 9:00 AM, Alex Harui wrote: >>>>>>>>> >>>>>>>>>> The default setting for Apache Flex is to not use RSLs because Adobe >>>>>>>>>> cannot sign the Apache Flex RSLs. That's probably why your SWF is >>>>>>>>> bigger. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/8/13 10:31 PM, "grimmwerks" <gr...@grimmwerks.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hey all - long time listener first time caller. >>>>>>>>>>> >>>>>>>>>>> I've taken a project that was originally 4.6 and I flipped it to >>>>> 4.9; >>>>>>>>>>> comparing the same code on two computers - when I build with the 4.6 >>>>>>>>>>> sdk I get a swf of 304k (with all the other extraneous libraries >>>>> such >>>>>>>>>>> as osmf, mx, sparkspins, etc) -- whereas with 4.9 the main sf is >>>>>>>>>>> 1.1mb -- that's a huge difference with no other changes in code no? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Garry Schafer >>>>>>>>>>> grimmwerks >>>>>>>>>>> gr...@grimmwerks.com >>>>>>>>>>> portfolio: www.grimmwerks.com/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Alex Harui >>>>>>>>>> Flex SDK Team >>>>>>>>>> Adobe Systems, Inc. >>>>>>>>>> http://blogs.adobe.com/aharui >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
