On 2/10/13 8:46 AM, "Harbs" <gavha...@gmail.com> wrote:
> 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?
You can load shared-code modules (effectively, your own custom RSL but
loaded after startup) for things the modules have in common.
> That could result in a total load size that's
> many times the size of a single app.
Even if the total download is higher, if start up time and the user
experience is better, it might be worth it.
>
> 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
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
