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
