Thanks. That was helpful. Harbs
On Feb 11, 2013, at 6:37 AM, Frédéric THOMAS wrote: > You can instruct the compiler to be clever, see > http://www.bit-101.com/blog/?p=941 > > -----Message d'origine----- From: Harbs > Sent: Sunday, February 10, 2013 5:46 PM > To: dev@flex.apache.org > Subject: Re: RSLs and signing > > Hmm. > > While thinking though the implications of using modules, I realized a > potential issue: > > Without RSLs, multiple modules means all that Flex code being compiled into > every one of the modules. Right? That could result in a total load size > that's many times the size of a single app. > > On Feb 10, 2013, at 6:30 PM, Alex Harui wrote: > >> >> >> >> On 2/10/13 8:18 AM, "Harbs" <gavha...@gmail.com> wrote: >> >>> >>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote: >>> >>>> >>>> >>>> >>>> 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. >>> >>> Not sure what you mean here. >> If you run a compile with the -link-report option, you can see what classes >> are being pulled in by other classes. That can help you think about how to >> refactor. >>> >>>> 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. >>> >>> Like I said, there are palettes that can be loaded as modules. It might or >>> might not help. The "image" is actually multiple objects rendered as Flex >>> components. Text is a customized RichEditableText component. (That's being >>> changed soon to a completely custom component due to limitations in >>> RichEditableText and our rendering requirements.) Images are compound >>> components with sub-elements, same goes for native objects. >> The "image" took several seconds to show up for me, so I think you could >> stick its widgets in a module, then it wouldn't delay the initial frame and >> you could post a progress bar. Or you could post a bitmap of the "image" >> and bring in the live version later. >>> >>>> 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. >>>> >>> >>> Interesting idea. The primary use of the app is integration into third party >>> websites, but I guess we can recommend that to our clients as well... >>> >>> >>>>> >>>>> 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 >>>> >>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >
