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 >
