You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2013/02/10 14:19:00 UTC
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
>> grimm@grimmwerks.com
>> portfolio: www.grimmwerks.com/
>>
>>
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: RSLs and signing
Posted by Frédéric THOMAS <we...@hotmail.com>.
The rsls from your domain is reused IIRC.
-----Message d'origine-----
From: Harbs
Sent: Sunday, February 10, 2013 3:01 PM
To: dev@flex.apache.org
Subject: Re: RSLs and signing
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.dutz@c-ware.de <
> christofer.dutz@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.lists@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
>>>> grimm@grimmwerks.com
>>>> portfolio: www.grimmwerks.com/
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>>
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> They are cached per-domain in the browser's cache. As a developer, you
> have to make the assumption that the browser cache is cleared when the
> browser closes
Thats the worse case and probably unlikely, the default settings for most (non mobile) browsers give a seizable cache (esp IE).
> as this is the default for some browsers that allow 3rd
> party plugins to store data in their cache like Chrome
Is that documented anywhere? As Flash is/was built into chrome is it considered 3rd party?
Thanks,
Justin
Re: RSLs and signing
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Justin,
They are cached per-domain in the browser's cache. As a developer, you
have to make the assumption that the browser cache is cleared when the
browser closes (as this is the default for some browsers that allow 3rd
party plugins to store data in their cache like Chrome). It *may* be
longer, but it is far from durable.
-Nick
On Sun, Feb 10, 2013 at 4:06 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> HI,
>
> > 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.
>
> Not correct. RSL will be cached by the Flash Player between sessions just
> like swfs are. Not having signed framework RSL just means that they are
> cached per domain not across all domains.
>
> From here:
> http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
>
> "Unsigned framework RSLs are cached in the browser cache and can only be
> used by applications that have access to the RSL's domain."
>
> Justin
>
>
Re: RSLs and signing
Posted by Avi Kessner <ak...@gmail.com>.
Interesting idea. I know that for google chrome you
could definitely leverage the user's chrome account.
Sounds like a fun side project for Chrome enthusiasts.
brought to you by the letters A, V, and I
and the number 47
On Mon, Feb 11, 2013 at 1:32 PM, Harbs <ga...@gmail.com> wrote:
> Okay. Here's a thought:
>
> What about using HTML local storage to store Apache RSLs that can be
> loaded as needed? Can anyone think of a workable way to do that? It won't
> work for all browsers, but it'll offer gains for the browsers that do, and
> it can have a fallback for the ones that don't.
>
> Harbs
>
> On Feb 11, 2013, at 1:18 PM, Kessler CTR Mark J wrote:
>
> > Well Apache RSL's (signed or unsigned) will be tossed in your regular
> browser cache. The Adobe signed ones are stored in a separate repository
> for the swz files n such. My Win7 path is located...
> >
> > C:\Users\[username]\AppData\Roaming\Adobe\Flash
> Player\AssetCache\[random letters]\
> >
> > This is persistent storage up to about 20MB or so. Whereas the ones
> from pretty much anyone else will get lost as soon as I clear my web
> browser cache.
> >
> > -Mark
>
>
RE: RSLs and signing
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Probably not. I like the idea of having shared libraries, but all the information would have to be able to run/validate from your main server. Being signed from Apache with would a be a completely different issue.
-Mark
-----Original Message-----
From: Harbs [mailto:gavharbs@gmail.com]
Sent: Monday, February 11, 2013 11:36 AM
To: dev@flex.apache.org
Subject: Re: RSLs and signing
I'm not really sure how it would/could work. But here's what I'm thinking:
My idea would be to somehow invoke something from the Apache domain which would store the data. The local stores are domain specific so I don't think you can directly access Apache's store from a different domain. If there's some way of then asking for the saved data to be passed from some code originating from Apache, we'd be guaranteed to be getting a known good version.
I have no idea if it's possible to do that cross domain communication or not...
On Feb 11, 2013, at 6:24 PM, Alex Harui wrote:
>
>
>
> On 2/11/13 3:32 AM, "Harbs" <ga...@gmail.com> wrote:
>
>> Okay. Here's a thought:
>>
>> What about using HTML local storage to store Apache RSLs that can be loaded as
>> needed? Can anyone think of a workable way to do that? It won't work for all
>> browsers, but it'll offer gains for the browsers that do, and it can have a
>> fallback for the ones that don't.
>>
> How does it work across domains? How do you verify that someone didn't
> overwrite the shared version with a bad version?
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
I'm not really sure how it would/could work. But here's what I'm thinking:
My idea would be to somehow invoke something from the Apache domain which would store the data. The local stores are domain specific so I don't think you can directly access Apache's store from a different domain. If there's some way of then asking for the saved data to be passed from some code originating from Apache, we'd be guaranteed to be getting a known good version.
I have no idea if it's possible to do that cross domain communication or not…
On Feb 11, 2013, at 6:24 PM, Alex Harui wrote:
>
>
>
> On 2/11/13 3:32 AM, "Harbs" <ga...@gmail.com> wrote:
>
>> Okay. Here's a thought:
>>
>> What about using HTML local storage to store Apache RSLs that can be loaded as
>> needed? Can anyone think of a workable way to do that? It won't work for all
>> browsers, but it'll offer gains for the browsers that do, and it can have a
>> fallback for the ones that don't.
>>
> How does it work across domains? How do you verify that someone didn't
> overwrite the shared version with a bad version?
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/11/13 3:32 AM, "Harbs" <ga...@gmail.com> wrote:
> Okay. Here's a thought:
>
> What about using HTML local storage to store Apache RSLs that can be loaded as
> needed? Can anyone think of a workable way to do that? It won't work for all
> browsers, but it'll offer gains for the browsers that do, and it can have a
> fallback for the ones that don't.
>
How does it work across domains? How do you verify that someone didn't
overwrite the shared version with a bad version?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
Okay. Here's a thought:
What about using HTML local storage to store Apache RSLs that can be loaded as needed? Can anyone think of a workable way to do that? It won't work for all browsers, but it'll offer gains for the browsers that do, and it can have a fallback for the ones that don't.
Harbs
On Feb 11, 2013, at 1:18 PM, Kessler CTR Mark J wrote:
> Well Apache RSL's (signed or unsigned) will be tossed in your regular browser cache. The Adobe signed ones are stored in a separate repository for the swz files n such. My Win7 path is located...
>
> C:\Users\[username]\AppData\Roaming\Adobe\Flash Player\AssetCache\[random letters]\
>
> This is persistent storage up to about 20MB or so. Whereas the ones from pretty much anyone else will get lost as soon as I clear my web browser cache.
>
> -Mark
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/11/13 3:58 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> This is persistent storage up to about 20MB or so. Whereas the ones from
>> pretty much anyone else will get lost as soon as I clear my web browser
>> cache.
>
> Which most users never never do. Unless the users of your application are
> developers :-)
I imagine that might be true for dedicated computers, but if you want your
app to work from a shared computer, I thought someone said browser caches
get cleared when closed.
Also, Flex has >1MB of RSLs so 20MB is less than 20 releases, and I hope we
will have more.
That's why I'm hoping the new framework I'm working on reduces the need for
RSLs.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This is persistent storage up to about 20MB or so. Whereas the ones from pretty much anyone else will get lost as soon as I clear my web browser cache.
Which most users never never do. Unless the users of your application are developers :-)
Justin
RE: RSLs and signing
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Well Apache RSL's (signed or unsigned) will be tossed in your regular browser cache. The Adobe signed ones are stored in a separate repository for the swz files n such. My Win7 path is located...
C:\Users\[username]\AppData\Roaming\Adobe\Flash Player\AssetCache\[random letters]\
This is persistent storage up to about 20MB or so. Whereas the ones from pretty much anyone else will get lost as soon as I clear my web browser cache.
-Mark
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> 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.
Not correct. RSL will be cached by the Flash Player between sessions just like swfs are. Not having signed framework RSL just means that they are cached per domain not across all domains.
From here:
http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
"Unsigned framework RSLs are cached in the browser cache and can only be used by applications that have access to the RSL's domain."
Justin
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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. :-(
Your application is already that size as the RSLs need to be downloaded if they are not cached.
> I'm still not sure why Flash can't cache third party signed RSLs,
They are cached in the browser cache. 3rd party RSL either one you make yourself or the 4.8/4.9 RSLs are caches for your domain just not across all domains.
Thanks,
Justin
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/11/13 3:08 AM, "Kessler CTR Mark J" <ma...@usmc.mil> wrote:
> Well you can still use RSLs if your user base will frequent your site multiple
> times in a day.
>
True, but if you don't use RSLs, you'll be storing less in their browser
cache.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: RSLs and signing
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Well you can still use RSLs if your user base will frequent your site multiple times in a day.
-----Original Message-----
From: Harbs [mailto:harbs.lists@gmail.com]
Sent: Sunday, February 10, 2013 9:54 AM
To: dev@flex.apache.org
Subject: Re: RSLs and signing
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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>> christofer.dutz@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.lists@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
>>>>>>>> grimm@grimmwerks.com
>>>>>>>> portfolio: www.grimmwerks.com/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alex Harui
>>>>>>> Flex SDK Team
>>>>>>> Adobe Systems, Inc.
>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: RSLs and signing
Posted by Avi Kessner <ak...@gmail.com>.
The benefits seem obvious to me. I remember a few projects where the client
only approved using flex when I explained how the rsl cacheing worked.
On Feb 11, 2013 7:25 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> > Where would we host it? I'm not sure Apache wants to serve binary RSLs.
> > Seems like it needs to be on an Akamai-type network, which I think costs
> > money.
>
> Obviously we'd need to ask Infra etc but I'm sure something would be
> possible. First we need to research what benefit is browser caching of the
> RSLs to a Flex app.
>
> Justin
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Where would we host it? I'm not sure Apache wants to serve binary RSLs.
> Seems like it needs to be on an Akamai-type network, which I think costs
> money.
Obviously we'd need to ask Infra etc but I'm sure something would be possible. First we need to research what benefit is browser caching of the RSLs to a Flex app.
Justin
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 2:07 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> Other than a cross domain policy what else would this require? I lot of JS
>> libraries do the same thing so it may be worth investigating. eg google
>> hosted libraries at https://developers.google.com/speed/libraries/
>
> Looks like this is possible (with fallbacks as well):
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf674ba-7f
> f6.html#WS2db454920e96a9e51e63e3d11c0bf69084-7ae0
>
> Obviously signed RSL cached by the flash player would be ideal but that's not
> happening. Using above instructions will a little effort it possible to use a
> RSLs from a central location that get cached in the browser cache, if the RSLs
> can't be downloaded it fallbacks to a alternative location (using the one the
> swf was served from is).
Where would we host it? I'm not sure Apache wants to serve binary RSLs.
Seems like it needs to be on an Akamai-type network, which I think costs
money.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Other than a cross domain policy what else would this require? I lot of JS libraries do the same thing so it may be worth investigating. eg google hosted libraries at https://developers.google.com/speed/libraries/
Looks like this is possible (with fallbacks as well):
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf674ba-7ff6.html#WS2db454920e96a9e51e63e3d11c0bf69084-7ae0
Obviously signed RSL cached by the flash player would be ideal but that's not happening. Using above instructions will a little effort it possible to use a RSLs from a central location that get cached in the browser cache, if the RSLs can't be downloaded it fallbacks to a alternative location (using the one the swf was served from is).
Thanks,
Justin
Re: RSLs and signing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
Which is also an advantage if a user visits a single application more than once.
> 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.
Even if we release more often users are likely to visit a given site more often than we make releases. If we released monthly and a user visited a site every day that's 29 times that user didn't need to download the RSLs (assuming they stayed in the browser cache for that long).
> I suppose we could try to host RSLs at some known place
Other than a cross domain policy what else would this require? I lot of JS libraries do the same thing so it may be worth investigating. eg google hosted libraries at https://developers.google.com/speed/libraries/
Thanks,
Justin
RE: RSLs and signing
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Links reports help a lot. It reduces modules down noticeably. However you have a harder time doing incremental compiling. There are a few instances where it doesn't compile the latest code properly.
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Sunday, February 10, 2013 11:09 AM
To: dev@flex.apache.org
Subject: Re: RSLs and signing
On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
On Feb 10, 2013, at 6:13 PM, Alex Harui wrote:
>
>
>
> On 2/10/13 8:00 AM, "Harbs" <ga...@gmail.com> wrote:
>
>> This is degenerating into a discussion that should probably move to the user
>> list, but...
>>
>> TLF is a must, but the whole TLF library shouldn't be more than 180-190 KB.
>>
>> Nothing like Datagrid is being used. I have a bunch of RichEditableText
>> components that I will probably factor out. That might help... On an aside, it
>> seems to me that the text components (even the spark ones) are pretty bloated
>> and over-engineered. I'm thinking of making some lightweight components for my
>> own purposes. Does anyone else see a need for lightweight versions?
>>
>> The only two mx components being used is ColorPicker and Alert. With the
>> newest release, I should be able to replace those two. I do have one Canvas
>> component in use because I couldn't get the behavior I needed with
>> BorderContainer. Maybe I'll revisit that. The odd thing was that switching to
>> "Spark only" did not bring up any errors for the Canvas component.
> And the first screen of your demo app doesn't seem to use multi-line text,
> so I would make sure Label is being used for all text which does not require
> TLF so you can load it later.
That's a no-go. TLF is required for rendering of the text on the page…
>
>>
>>
>> On Feb 10, 2013, at 5:47 PM, Nicholas Kwiatkowski wrote:
>>
>>> The caching rules of RSLs and SWFs are for the most part, are the same.
>>>
>>> Depending on your IDE, you may be able to build a dependency tree, which
>>> should help you determine where your bulk is coming from. I find that
>>> certain components (mx:DataGrid, for example), add in about 250k just for
>>> being there because of all the things it depends on. Some of the Spark
>>> text components are equally as heavy because of their dependence on the TLF
>>> stuff. If you could stop using all of the halo components, you will
>>> probably be much better off as well.
>>>
>>> -Nick
>>>
>>>
>>>
>>> On Sun, Feb 10, 2013 at 10:41 AM, Harbs <ha...@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?
>>>>
>>>> If I'm reading you right, the caching of swfs is actually more persistent
>>>> than the caching of unsigned RSLs. Right?
>>>>
>>>> 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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>>> grimm@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
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 8:00 AM, "Harbs" <ga...@gmail.com> wrote:
> This is degenerating into a discussion that should probably move to the user
> list, but...
>
> TLF is a must, but the whole TLF library shouldn't be more than 180-190 KB.
>
> Nothing like Datagrid is being used. I have a bunch of RichEditableText
> components that I will probably factor out. That might help... On an aside, it
> seems to me that the text components (even the spark ones) are pretty bloated
> and over-engineered. I'm thinking of making some lightweight components for my
> own purposes. Does anyone else see a need for lightweight versions?
>
> The only two mx components being used is ColorPicker and Alert. With the
> newest release, I should be able to replace those two. I do have one Canvas
> component in use because I couldn't get the behavior I needed with
> BorderContainer. Maybe I'll revisit that. The odd thing was that switching to
> "Spark only" did not bring up any errors for the Canvas component.
And the first screen of your demo app doesn't seem to use multi-line text,
so I would make sure Label is being used for all text which does not require
TLF so you can load it later.
>
>
> On Feb 10, 2013, at 5:47 PM, Nicholas Kwiatkowski wrote:
>
>> The caching rules of RSLs and SWFs are for the most part, are the same.
>>
>> Depending on your IDE, you may be able to build a dependency tree, which
>> should help you determine where your bulk is coming from. I find that
>> certain components (mx:DataGrid, for example), add in about 250k just for
>> being there because of all the things it depends on. Some of the Spark
>> text components are equally as heavy because of their dependence on the TLF
>> stuff. If you could stop using all of the halo components, you will
>> probably be much better off as well.
>>
>> -Nick
>>
>>
>>
>> On Sun, Feb 10, 2013 at 10:41 AM, Harbs <ha...@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?
>>>
>>> If I'm reading you right, the caching of swfs is actually more persistent
>>> than the caching of unsigned RSLs. Right?
>>>
>>> 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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
This is degenerating into a discussion that should probably move to the user list, but…
TLF is a must, but the whole TLF library shouldn't be more than 180-190 KB.
Nothing like Datagrid is being used. I have a bunch of RichEditableText components that I will probably factor out. That might help… On an aside, it seems to me that the text components (even the spark ones) are pretty bloated and over-engineered. I'm thinking of making some lightweight components for my own purposes. Does anyone else see a need for lightweight versions?
The only two mx components being used is ColorPicker and Alert. With the newest release, I should be able to replace those two. I do have one Canvas component in use because I couldn't get the behavior I needed with BorderContainer. Maybe I'll revisit that. The odd thing was that switching to "Spark only" did not bring up any errors for the Canvas component.
On Feb 10, 2013, at 5:47 PM, Nicholas Kwiatkowski wrote:
> The caching rules of RSLs and SWFs are for the most part, are the same.
>
> Depending on your IDE, you may be able to build a dependency tree, which
> should help you determine where your bulk is coming from. I find that
> certain components (mx:DataGrid, for example), add in about 250k just for
> being there because of all the things it depends on. Some of the Spark
> text components are equally as heavy because of their dependence on the TLF
> stuff. If you could stop using all of the halo components, you will
> probably be much better off as well.
>
> -Nick
>
>
>
> On Sun, Feb 10, 2013 at 10:41 AM, Harbs <ha...@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?
>>
>> If I'm reading you right, the caching of swfs is actually more persistent
>> than the caching of unsigned RSLs. Right?
>>
>> 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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>> grimm@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
>>>
>>
>>
Re: RSLs and signing
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
The caching rules of RSLs and SWFs are for the most part, are the same.
Depending on your IDE, you may be able to build a dependency tree, which
should help you determine where your bulk is coming from. I find that
certain components (mx:DataGrid, for example), add in about 250k just for
being there because of all the things it depends on. Some of the Spark
text components are equally as heavy because of their dependence on the TLF
stuff. If you could stop using all of the halo components, you will
probably be much better off as well.
-Nick
On Sun, Feb 10, 2013 at 10:41 AM, Harbs <ha...@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?
>
> If I'm reading you right, the caching of swfs is actually more persistent
> than the caching of unsigned RSLs. Right?
>
> 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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
> >>>>>>> christofer.dutz@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.lists@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
> >>>>>>>>>> grimm@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
> >
>
>
AW: RSLs and signing
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
Utilizing the linkage-reports is one thing that's particularly easy to configure when building using Flexmojos :-)
I wrote up all sorts of size-reduction options with Flex and Flexmojos in my wiki: https://dev.c-ware.de/confluence/display/PUBLIC/Optimizing+your+build
The biggest optimization I could get, was using Apparat to optimize the built swcs and swfs.
Eventually it helps :-)
Chris
________________________________________
Von: Harbs [gavharbs@gmail.com]
Gesendet: Montag, 11. Februar 2013 08:20
An: dev@flex.apache.org
Betreff: Re: RSLs and signing
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" <ga...@gmail.com> wrote:
>>
>>>
>>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>>>> grimm@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
>>
>
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
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" <ga...@gmail.com> wrote:
>>
>>>
>>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>>>> grimm@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
>>
>
Re: RSLs and signing
Posted by Frédéric THOMAS <we...@hotmail.com>.
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" <ga...@gmail.com> wrote:
>
>>
>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>>
>>>
>>>
>>>
>>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>>> grimm@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
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 11:20 PM, "Harbs" <ga...@gmail.com> wrote:
> Interesting. That sounds like a good approach.
>
> How do you set this up in Flash Builder?
I've never tried it in FlashBuilder, but as the bit-101.com article
explains, it is pretty much all about generating -link-reports and using
-load-externs appropriately. You can specify -load-externs for each of
multiple -link-reports
> Assigning externs that are in the
> main app seems pretty straight-forward, but I'm not clear on how you'd
> instruct the compiler to exclude classes from another module (and the main
> app).
>
> On Feb 11, 2013, at 6:36 AM, Alex Harui wrote:
>
>>> 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.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
Interesting. That sounds like a good approach.
How do you set this up in Flash Builder? Assigning externs that are in the main app seems pretty straight-forward, but I'm not clear on how you'd instruct the compiler to exclude classes from another module (and the main app).
On Feb 11, 2013, at 6:36 AM, Alex Harui wrote:
>> 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.
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 8:46 AM, "Harbs" <ga...@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" <ga...@gmail.com> wrote:
>>
>>>
>>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
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" <ga...@gmail.com> wrote:
>
>>
>> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>>
>>>
>>>
>>>
>>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>>> grimm@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
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 8:36 AM, "Harbs" <ga...@gmail.com> wrote:
>
> On Feb 10, 2013, at 6:30 PM, Alex Harui wrote:
>
>>> 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.
>
> That's something to think about. I'm not sure downloading a preview of the
> page is worthwhile. The biggest reason for the delay is usually downloading
> fonts. The number of fonts downloaded before the page is rendered depends
> heavily on the individual documents. I have plans on optimizing the font
> loading and at least giving some visual feedback of what's going onŠ ;-)
If you can create a low res preview that loads in half a second (about 40K
for me), you could display it with a blur effect or something and even
change the blur as a progress indicator while everything else is being
downloaded. It might even look like a progressive JPG or something like
that.
Also, for repeat customers, you can store the preview in the local
SharedObject.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
On Feb 10, 2013, at 6:30 PM, Alex Harui wrote:
>> 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.
That's something to think about. I'm not sure downloading a preview of the page is worthwhile. The biggest reason for the delay is usually downloading fonts. The number of fonts downloaded before the page is rendered depends heavily on the individual documents. I have plans on optimizing the font loading and at least giving some visual feedback of what's going on… ;-)
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 8:18 AM, "Harbs" <ga...@gmail.com> wrote:
>
> On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>
>>
>>
>>
>> On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ga...@gmail.com>.
On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
>
>
>
> On 2/10/13 7:41 AM, "Harbs" <ha...@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.
> 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.
> 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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>>> grimm@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
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/13 7:41 AM, "Harbs" <ha...@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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ha...@gmail.com>.
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?
If I'm reading you right, the caching of swfs is actually more persistent than the caching of unsigned RSLs. Right?
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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>>> christofer.dutz@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.lists@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
>>>>>>>>>> grimm@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
>
Re: RSLs and signing
Posted by Alex Harui <ah...@adobe.com>.
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" <ha...@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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>>> christofer.dutz@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.lists@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
>>>>>>>>> grimm@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
Re: RSLs and signing
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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.dutz@c-ware.de <
>>>>> christofer.dutz@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.lists@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
>>>>>>>> grimm@grimmwerks.com
>>>>>>>> portfolio: www.grimmwerks.com/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alex Harui
>>>>>>> Flex SDK Team
>>>>>>> Adobe Systems, Inc.
>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: RSLs and signing
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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 <ha...@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 <ha...@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.dutz@c-ware.de <
> >>> christofer.dutz@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.lists@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
> >>>>>> grimm@grimmwerks.com
> >>>>>> portfolio: www.grimmwerks.com/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Alex Harui
> >>>>> Flex SDK Team
> >>>>> Adobe Systems, Inc.
> >>>>> http://blogs.adobe.com/aharui
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: RSLs and signing
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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.dutz@c-ware.de <
>>> christofer.dutz@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.lists@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
>>>>>> grimm@grimmwerks.com
>>>>>> portfolio: www.grimmwerks.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>>>>
>>>>
>>>>
>>
>>
Re: RSLs and signing
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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 <ha...@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.dutz@c-ware.de <
> > christofer.dutz@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.lists@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
> >>>> grimm@grimmwerks.com
> >>>> portfolio: www.grimmwerks.com/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Alex Harui
> >>> Flex SDK Team
> >>> Adobe Systems, Inc.
> >>> http://blogs.adobe.com/aharui
> >>>
> >>
> >>
>
>
Re: RSLs and signing
Posted by Harbs <ha...@gmail.com>.
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.dutz@c-ware.de <
> christofer.dutz@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.lists@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
>>>> grimm@grimmwerks.com
>>>> portfolio: www.grimmwerks.com/
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>>
Re: RSLs and signing
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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.dutz@c-ware.de <
christofer.dutz@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.lists@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
> >> grimm@grimmwerks.com
> >> portfolio: www.grimmwerks.com/
> >>
> >>
> >>
> >>
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
>
>
AW: RSLs and signing
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
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.lists@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
>> grimm@grimmwerks.com
>> portfolio: www.grimmwerks.com/
>>
>>
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>