flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: RSLs and signing
Date Sun, 10 Feb 2013 16:08:51 GMT



On 2/10/13 7:41 AM, "Harbs" <harbs.lists@gmail.com> wrote:

> The numbers were for release.
> 
> The debug size using RSLs is about 1 MB.
> 
> I'm not really sure if modules can help. There are not many modular components
> in the app. Maybe I can load the image browser as a module, but I don't know
> how much of a difference that will make. There are a number of palettes that
> might be candidates. I'll see what I can do on that front, but I don't have
> high hopes. My bigger concern is really the Flex libs which have more bulk
> than the whole app... Is there a good way of figuring out where the bulk is
> coming from?
Link-reports might help.

I went to your demo page at:
https://printui.com/web-to-print-demo-step-1.php

The first screen just looks like buttons and an image loader to me.  That
shouldn't be that big.  As soon as the image loads, I would request load of
a module of other UI widgets and associated logic while the user is
pondering what to do next.

I don't know about the ethics of it, but since your landing pages are php,
I'm not sure why you couldn't start pre-loading other SWFs after the page is
displayed so more stuff is there if the user continues on.

> 
> If I'm reading you right, the caching of swfs is actually more persistent than
> the caching of unsigned RSLs. Right?
RSLs and SWFs have the same caching rules in the browser.  The issue is the
probability of a cache-miss.  The signed RSL cache in the player prevented
cache-misses if the user had no browser cache or emptied the cache or had
limits on cache size.

> 
> On Feb 10, 2013, at 5:19 PM, Alex Harui wrote:
> 
>> The only advantage to un-signed RSLs is if you serve more than one SWF that
>> uses them from your domain.  SWFs end up on disk in a browser cache (if
>> there is one and within the limitations of that cache) so then there is a
>> probability you won't have to download some code.
>> 
>> Apache Flex will hopefully release often.  The Framework RSLs were
>> version-specific, so releasing often further lowers your chances of any
>> benefit even if we did have a way to serve cross-domain RSLs.
>> 
>> I suppose we could try to host RSLs at some known place, but browser cache
>> limitations would still apply, and you'd want a custom domain name otherwise
>> you'd expose yourself to cross-domain scripting.
>> 
>> Are your SWF size numbers for release mode or debug mode?  Using modules
>> carefully can lower the size of the initial load.
>> 
>> 
>> On 2/10/13 6:54 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>> 
>>> Okay. Like you said this sucks.
>>> 
>>> I'm looking to moving from Flex 4.5 to 4.9 in the next few weeks. I just
>>> changed my compile settings to merge instead of using RSLs and the app went
>>> from a little over 600 KB to 1.4 MB. :-(
>>> 
>>> I clearly have a lot of work to do removing dependency on a lot of classes
>>> and
>>> getting rid of dependency on mx components (I have a very few in use, but
>>> the
>>> ones that I'm using will be hard to replace with Spark.)
>>> 
>>> I'm still not sure why Flash can't cache  third party signed RSLs, but
>>> there's
>>> not much to be gained by kvetching about it. I doubt they'll add that as a
>>> feature to FlashŠ
>>> 
>>> Harbs
>>> 
>>> On Feb 10, 2013, at 4:37 PM, Nicholas Kwiatkowski wrote:
>>> 
>>>> When I say signed, I'm meaning signed by Adobe.  There really is
>>>> little benefit to sign an RSL with our certificates, as they are in the web
>>>> of trust of the Flash Player.
>>>> 
>>>> From what I've been told, unless it is signed by Adobe, it is not in
>>>> the persistent cache, so it is not cached on disk, period.  This is
>>>> regardless of the domain that it is on.
>>>> 
>>>> This came up VERY early on (maybe even at the Tech Summit -- I don't know,
>>>> I wasn't there), and Adobe was pretty straight forward that this was going
>>>> to be the case.  Questions came up about having them sign it, but they did
>>>> not want to dedicated the resources to do it. Looking back, it would have
>>>> been a pain to have to submit our releases to Adobe for their complete
>>>> review before we could do anything -- potentially holding back our releases
>>>> weeks or months.
>>>> 
>>>> It was seen as a majority of the Flex work was moving to mobile.  On AIR
>>>> with mobile, there is no concept of RSLs (everything is embedded within the
>>>> final executable), so it was seen as less of an issue.
>>>> 
>>>> -Nick
>>>> 
>>>> On Sun, Feb 10, 2013 at 9:27 AM, Harbs <harbs.lists@gmail.com> wrote:
>>>> 
>>>>> Bah! So they're totally useless.
>>>>> 
>>>>> swfs are also cached by the browser for that session. Correct?
>>>>> 
>>>>> Is there any logic to not caching RSLs for the domain that loaded them?
>>>>> 
>>>>>> Only signed RSLs are cached on disk.
>>>>> 
>>>>> Signed meaning signed by Adobe. Right? There's no way to sign a RSL with
>>>>> an SSL or code signing certificate. Is there?
>>>>> 
>>>>> On Feb 10, 2013, at 4:19 PM, Nicholas Kwiatkowski wrote:
>>>>> 
>>>>>> They are downloaded once per domain, per session.  If you visit domain
>>>>>> x.comtwice in a session (as defined by your browser), then it will
>>>>>> stay in
>>>>>> memory.  If you close your session (typically by closing your browser),
>>>>>> then it will be cleared from memory.
>>>>>> 
>>>>>> Only signed RSLs are cached on disk.
>>>>>> 
>>>>>> -Nick
>>>>>> 
>>>>>> On Sun, Feb 10, 2013 at 9:01 AM, Harbs <harbs.lists@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" <grimm@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


Mime
View raw message