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
