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" <gavha...@gmail.com> wrote:
On Feb 10, 2013, at 6:08 PM, Alex Harui wrote:
On 2/10/13 7:41 AM, "Harbs" <harbs.li...@gmail.com> wrote:
The numbers were for release.
The debug size using RSLs is about 1 MB.
I'm not really sure if modules can help. There are not many modular
components
in the app. Maybe I can load the image browser as a module, but I don't
know
how much of a difference that will make. There are a number of palettes
that
might be candidates. I'll see what I can do on that front, but I don't
have
high hopes. My bigger concern is really the Flex libs which have more
bulk
than the whole app... Is there a good way of figuring out where the
bulk is
coming from?
Link-reports might help.
Not sure what you mean here.
If you run a compile with the -link-report option, you can see what
classes
are being pulled in by other classes. That can help you think about how
to
refactor.
I went to your demo page at:
https://printui.com/web-to-print-demo-step-1.php
The first screen just looks like buttons and an image loader to me.
That
shouldn't be that big. As soon as the image loads, I would request load
of
a module of other UI widgets and associated logic while the user is
pondering what to do next.
Like I said, there are palettes that can be loaded as modules. It might
or
might not help. The "image" is actually multiple objects rendered as Flex
components. Text is a customized RichEditableText component. (That's
being
changed soon to a completely custom component due to limitations in
RichEditableText and our rendering requirements.) Images are compound
components with sub-elements, same goes for native objects.
The "image" took several seconds to show up for me, so I think you could
stick its widgets in a module, then it wouldn't delay the initial frame
and
you could post a progress bar. Or you could post a bitmap of the "image"
and bring in the live version later.
I don't know about the ethics of it, but since your landing pages are
php,
I'm not sure why you couldn't start pre-loading other SWFs after the
page is
displayed so more stuff is there if the user continues on.
Interesting idea. The primary use of the app is integration into third
party
websites, but I guess we can recommend that to our clients as well...
If I'm reading you right, the caching of swfs is actually more
persistent
than
the caching of unsigned RSLs. Right?
RSLs and SWFs have the same caching rules in the browser. The issue is
the
probability of a cache-miss. The signed RSL cache in the player
prevented
cache-misses if the user had no browser cache or emptied the cache or
had
limits on cache size.
On Feb 10, 2013, at 5:19 PM, Alex Harui wrote:
The only advantage to un-signed RSLs is if you serve more than one SWF
that
uses them from your domain. SWFs end up on disk in a browser cache
(if
there is one and within the limitations of that cache) so then there
is a
probability you won't have to download some code.
Apache Flex will hopefully release often. The Framework RSLs were
version-specific, so releasing often further lowers your chances of
any
benefit even if we did have a way to serve cross-domain RSLs.
I suppose we could try to host RSLs at some known place, but browser
cache
limitations would still apply, and you'd want a custom domain name
otherwise
you'd expose yourself to cross-domain scripting.
Are your SWF size numbers for release mode or debug mode? Using
modules
carefully can lower the size of the initial load.
On 2/10/13 6:54 AM, "Harbs" <harbs.li...@gmail.com> wrote:
Okay. Like you said this sucks.
I'm looking to moving from Flex 4.5 to 4.9 in the next few weeks. I
just
changed my compile settings to merge instead of using RSLs and the
app
went
from a little over 600 KB to 1.4 MB. :-(
I clearly have a lot of work to do removing dependency on a lot of
classes
and
getting rid of dependency on mx components (I have a very few in use,
but
the
ones that I'm using will be hard to replace with Spark.)
I'm still not sure why Flash can't cache third party signed RSLs,
but
there's
not much to be gained by kvetching about it. I doubt they'll add that
as a
feature to FlashŠ
Harbs
On Feb 10, 2013, at 4:37 PM, Nicholas Kwiatkowski wrote:
When I say signed, I'm meaning signed by Adobe. There really is
little benefit to sign an RSL with our certificates, as they are in
the
web
of trust of the Flash Player.
From what I've been told, unless it is signed by Adobe, it is not in
the persistent cache, so it is not cached on disk, period. This is
regardless of the domain that it is on.
This came up VERY early on (maybe even at the Tech Summit -- I don't
know,
I wasn't there), and Adobe was pretty straight forward that this was
going
to be the case. Questions came up about having them sign it, but
they
did
not want to dedicated the resources to do it. Looking back, it would
have
been a pain to have to submit our releases to Adobe for their
complete
review before we could do anything -- potentially holding back our
releases
weeks or months.
It was seen as a majority of the Flex work was moving to mobile. On
AIR
with mobile, there is no concept of RSLs (everything is embedded
within
the
final executable), so it was seen as less of an issue.
-Nick
On Sun, Feb 10, 2013 at 9:27 AM, Harbs <harbs.li...@gmail.com>
wrote:
Bah! So they're totally useless.
swfs are also cached by the browser for that session. Correct?
Is there any logic to not caching RSLs for the domain that loaded
them?
Only signed RSLs are cached on disk.
Signed meaning signed by Adobe. Right? There's no way to sign a RSL
with
an SSL or code signing certificate. Is there?
On Feb 10, 2013, at 4:19 PM, Nicholas Kwiatkowski wrote:
They are downloaded once per domain, per session. If you visit
domain
x.comtwice in a session (as defined by your browser), then it will
stay in
memory. If you close your session (typically by closing your
browser),
then it will be cleared from memory.
Only signed RSLs are cached on disk.
-Nick
On Sun, Feb 10, 2013 at 9:01 AM, Harbs <harbs.li...@gmail.com>
wrote:
I apparently missed this. Yes. It does suck. Are RSLs reloaded
every
time
for a specific domain, or is it just a cross-domain issue?
If I use RSLs for Flex 4.9 and I update my main app, do the RSLs
get
downloaded every time, or will the RSLs from my domain be reused?
Is
there
any point in using RSLs at all?
On Feb 10, 2013, at 3:56 PM, Nicholas Kwiatkowski wrote:
Adobe has (had?) a pretty good explanation on their Flash
Whitepaper.
It
boils down to this :
- They are no longer in control of Flex
- They are no longer doing security reviews of the source code
- They have to sign the Flex package with their security
certificate
in
order for it to be stored in the Flash RSL Cache
- They won't sign it anymore because they would be responsible
for
any
security issues that may come out of it.
Yes, it sucks, but unfortunately, we have to live with it.
-Nick
On Sun, Feb 10, 2013 at 8:49 AM, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:
I have to admit, that I don't quite understand what the
inability to
create signed rsls has to do with the usage of rsls themselves.
The problem is that the Flashplayer is able to install rsls
that are
signed by Adobe. Usually the Adobe FDK rsls were also available
in
signed
versions (swz files). These were dynamically loaded the first
time
they
were needed and installed by the Flashplayer. The second time
the
libs
were
needed the installed versions were used reducing the download
time
dramatically. Now the problem is that Adobe won't sign Apache
SWCs
as
they
are no longer in charge of the libs code (Understandable).
Giving
Apache a
key to be able to also create signed RSLs would eventually open
serious
security problems because a signed manipulated swz would be
used by
every
other website using the same version of a given lib.
Coming back to the RSLs ... The difference between a signed and
an
unsigned RSL is just, that the unsigned rsl is loaded on every
visit
of
a
user. As far as I know there is no other difference. So I don't
quite
understand why the lack of availability of signed rsls should
have
any
effect on built applications and the default linking type.
Chris
-----Ursprüngliche Nachricht-----
Von: Harbs [mailto:harbs.li...@gmail.com]
Gesendet: Sonntag, 10. Februar 2013 14:19
An: dev@flex.apache.org
Betreff: RSLs and signing
I did not realize that Apache Flex does not use RSLs by
default.
What's the story with signing? Is that an issue with
cross-domain
security? Is there any way to get an Apache signature approved
for
Flash?
Either way, I'd imagine I'd want RSLs for the simple reason
that
updating
apps should result in a smaller download.
Harbs
On Feb 9, 2013, at 9:00 AM, Alex Harui wrote:
The default setting for Apache Flex is to not use RSLs because
Adobe
cannot sign the Apache Flex RSLs. That's probably why your
SWF is
bigger.
On 2/8/13 10:31 PM, "grimmwerks" <gr...@grimmwerks.com> wrote:
Hey all - long time listener first time caller.
I've taken a project that was originally 4.6 and I flipped it
to
4.9;
comparing the same code on two computers - when I build with
the
4.6
sdk I get a swf of 304k (with all the other extraneous
libraries
such
as osmf, mx, sparkspins, etc) -- whereas with 4.9 the main sf
is
1.1mb -- that's a huge difference with no other changes in
code no?
Garry Schafer
grimmwerks
gr...@grimmwerks.com
portfolio: www.grimmwerks.com/
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
