I think we should also look at the Flash globalization implementation
before deciding whether to use CLDR or not.
My biggest concern with Flash globalization is how it behaves on different
operating systems, any experience with it?
Another thing is the fact that it uses the locale settings of the
On 2/20/12 7:33 PM, "Justin Mclean" wrote:
> Hi,
>
>> Definitely no need to wait to commit changes for which there are no Mustella
>> tests. However, I thought we were going to try to cut a release that was
>> close to "parity" first.
> Can we do that without Mustella? or the compiler?
Sure.
I mean add-on / extension. https://addons.mozilla.org/en-US/firefox/
Not every browser supports add-ons either tho. What I was thinking was a
sidebar that showed something like the package explorer or even an
extension that took, "http://localhost/my_application.mxml"; and ran mxmlc
on it (which t
Hi,
> Definitely no need to wait to commit changes for which there are no Mustella
> tests. However, I thought we were going to try to cut a release that was
> close to "parity" first.
Can we do that without Mustella? or the compiler? I guess the question is do we
wait around until we have every
Hi,
> Believe the suggestion is that we check against CLDR.
I think the date format and currency format is the only overlap with the CDLR
and the Flex resource files.
/frameworks/projects/airframework/bundles//aircontrols.properties
fileSystemDataGrid_dateFormatString=x
/frameworks/proje
>HI ,
>
>I've taken a quick look at the CDLR it basically give timezone, date, time and
>currency formatting information for a wide range of locales. Quite useful.
>eg http://unicode.org/cldr/trac/browser/tags/release-21/common/main/en_AU.xml
>
>It may be possible to download this and as part of t
HI ,
I've taken a quick look at the CDLR it basically give timezone, date, time and
currency formatting information for a wide range of locales. Quite useful.
eg http://unicode.org/cldr/trac/browser/tags/release-21/common/main/en_AU.xml
It may be possible to download this and as part of the fram
>> there's already a "global" locale resource here: http://cldr.unicode.org/
>Thanks I was unaware of that, however I'm not exactly sure how it relates to
>the Flex SDK resource files. Are you suggesting that the Flex SDK use CLDR in
>some way? Or that we check that the existing resource files
Hi,
>> Also you can you can compile any other changes you
>> require right into the Flex framework. This makes RSLs actually usable again.
> I'm not sure I understood this.
We can compile our own framework RSLs by applying any unsubmitted monkey
patches directly to a local copy of the source cod
HI,
> there's already a "global" locale resource here: http://cldr.unicode.org/
Thanks I was unaware of that, however I'm not exactly sure how it relates to
the Flex SDK resource files. Are you suggesting that the Flex SDK use CLDR in
some way? Or that we check that the existing resource files
On 2/20/12 3:51 PM, "arielj...@yahoo.com" wrote:
> Can we program the loader to pull the hash from a URL via ssl?
There are lots of possibilities. Basically, if you are fetching the answer
to a question, you allow both the question and answer to be hacked to get
any answer you want. It will
On 2/20/12 1:02 PM, "Justin Mclean" wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fix bugs.
> Once the the project is up and running fully (people submitting patches etc
> etc) this will be less of an i
On 2/20/2012 7:48 PM, Justin Mclean wrote:
Hi,
If any other British or Australia person can review the patches submitted and
comment in JIRA I'm sure that will help the patch to get accepted.
https://issues.apache.org/jira/browse/FLEX-16
If it helps I should be able to generate a difference b
On 2/20/12 5:15 PM, "Justin Mclean" wrote:
> Hi there.
>
>> Now that Carol has gotten the trunk populated, I was wondering if we need to
>> wait until the Mustella tests are in before committing to trunk?
> Just as an aside I've selected those issues as it was something that could be
> easily
On 2/20/12 11:40 AM, "Michael A. Labriola"
wrote:
>
> I always thought it would be interesting to stream the first two frames from a
> server. Then keep alive the connection, use some connection to a server to
> indicate which classes were needed next and just stream additional frames each
>
Hi there.
> Now that Carol has gotten the trunk populated, I was wondering if we need to
> wait until the Mustella tests are in before committing to trunk?
Just as an aside I've selected those issues as it was something that could be
easily verified without Mustella (ie no real framework code ch
On Feb 20, 2012, at 6:02 PM, Bertrand Delacretaz wrote:
> On Mon, Feb 20, 2012 at 4:42 PM, Jun Heider wrote:
>>
>> Is the JIRA hooked up to the SVN repo? For instance being able to add a
>> "RE: {Ticket Number}" to the commit message?
>
> Yes, if you start a commit message with FLEX-1234 the c
On Mon, Feb 20, 2012 at 4:42 PM, Jun Heider wrote:
>
> On Feb 20, 2012, at 5:38 PM, Bertrand Delacretaz wrote:
> ...I think personally, with JIRA being around my preference would be a
> Review-Then-Commit.
> Is the JIRA hooked up to the SVN repo? For instance being able to add a
> "RE: {Ticket Nu
On Feb 20, 2012, at 5:38 PM, Bertrand Delacretaz wrote:
> On Mon, Feb 20, 2012 at 4:30 PM, Jun Heider wrote:
>> ...have we decided on a standard process for committing to trunk? For
>> instance is +1 voting on the ML the
>> Apache version of code reviews - I hope not since that seems like it'd
On Feb 20, 2012, at 5:37 PM, Michael A. Labriola wrote:
>
> Jun,
>
> Thanks for asking. I was looking at the same thing today for Justin's patch.
>
> Mike
>
Yep, Justin's patches are the ones I noticed. Thanks Justin! :)
On Mon, Feb 20, 2012 at 4:30 PM, Jun Heider wrote:
> ...have we decided on a standard process for committing to trunk? For
> instance is +1 voting on the ML the
> Apache version of code reviews - I hope not since that seems like it'd be too
> slow and cumbersome...
The most common way in Apache
>Now that Carol has gotten the trunk populated, I was wondering if we need to
>wait until the Mustella tests are in before committing to trunk? The reason I
>ask is I know that there's been some patches submitted to the JIRA >tickets
>and it would be nice to start getting work committed.
>
>On a
Now that Carol has gotten the trunk populated, I was wondering if we need to
wait until the Mustella tests are in before committing to trunk? The reason I
ask is I know that there's been some patches submitted to the JIRA tickets and
it would be nice to start getting work committed.
On another
On Mon, Feb 20, 2012 at 1:16 PM, Nicholas Kwiatkowski wrote:
> https://github.com/apache/flex
See also http://git.apache.org/ for other mirrors and docs about how
to use them.
-Bertrand
Can we program the loader to pull the hash from a URL via ssl?
Ariel Jakobovits
ajako...@adobe.com
650-350-0282
On Feb 20, 2012, at 1:02 PM, Justin Mclean wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fi
Hi,
> Now that we have the subversion code from Adobe, who's going to work on
> creating a git mirror of it?
Believe it's already done (although I've not checked it out).
https://issues.apache.org/jira/browse/INFRA-4366
You can also use git-svn to check the code out of SVN into a local git
repos
Already done :)
https://github.com/apache/flex
-Nick
On Mon, Feb 20, 2012 at 4:10 PM, Michel Boudreau
wrote:
> Now that we have the subversion code from Adobe, who's going to work on
> creating a git mirror of it?
>
> M
>
> On Tue, Feb 14, 2012 at 7:01 PM, Deirdre Holub >wrote:
>
> > Given the
Now that we have the subversion code from Adobe, who's going to work on
creating a git mirror of it?
M
On Tue, Feb 14, 2012 at 7:01 PM, Deirdre Holub wrote:
> Given the conversation on this thread, should the status page be
> recommending building proposals at github (bullet points two and three
Hi,
> Also note that many large apps seem to have given up on RSLs because they've
> had to hack the classes in the RSLs to fix bugs.
Once the the project is up and running fully (people submitting patches etc
etc) this will be less of an issue as there will be less need to monkey patch
any Flex
On 21/02/2012 04:36, Haykel BEN JEMIA wrote:
loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
attack.
The purpose of the loader is that a application that is loaded uses
verified libraries. If the initial
access to the embedded loader.swf is corrupted by a m-i-t-m then
>wouldn't that be essentially the same as them "blessing" our framework, which
>is something they were unwilling to do in the first place? From what I
>remember, that is the entire beef they had -- they didn't want to say that our
>>framework was worthy of an RSL, unless it went through their s
wouldn't that be essentially the same as them "blessing" our framework,
which is something they were unwilling to do in the first place? From what
I remember, that is the entire beef they had -- they didn't want to say
that our framework was worthy of an RSL, unless it went through their
security
Technically, any editor should, if you do `use namespace mx_internal` :) I
can remember that FD ignored the [Exclude] metadata - that's for sure. In
any case, the fact that it's not in the autocompletion is a side effect,
probably due to the editors not handling all of the AS3 syntax properly. I
th
>Flex does not leverage that aspect of Flash. Like Java, it has code
>libraries which can be substantial in size. Unlike Java, it does not
>supported class loading on the fly. You have to preload the code before
>making access to a class.
Alex,
I always had a theory I wanted to try out but n
loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
attack.
Sorry for the short message. Sent from my tablet.
Le 20 févr. 2012 20:29, "Martin Heidegger" a écrit :
> On 21/02/2012 04:18, Alex Harui wrote:
>
>> I don't think we can find a way to know that a file downloaded f
On 21/02/2012 04:18, Alex Harui wrote:
I don't think we can find a way to know that a file downloaded from one mirror
is
the same as one coming from another mirror without downloading it in the
first place.
What is wrong about an approach where the "loader.swf" has MD5 hash of
the files? It
has
On 2/20/12 9:26 AM, "Bertrand Delacretaz" wrote:
> Hi Omar,
>
> On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
> wrote:
>
> In the case of RSLs I assume signatures are checked by the client,
> what are the requirements for that?
RSL signatures are checked by the Flash Player.
Flash is a ze
On Mon, Feb 20, 2012 at 8:04 PM, Jeffry Houser wrote:
> On 2/20/2012 1:46 PM, Left Right wrote:
>
>> Jeffry, what code shows up in the editor really depends on the editor you
>> are using, that's not universal, and stuff in mx_internal may show as
>> well,
>>
> Which code editor will show that st
On 2/20/2012 1:46 PM, Left Right wrote:
Jeffry, what code shows up in the editor really depends on the editor you
are using, that's not universal, and stuff in mx_internal may show as well,
Which code editor will show that stuff?
if you wanted it to. However, Flash Builder also used various
On 2/20/12 1:09 AM, "jude" wrote:
> What about a browser plug in that would handle .mxml files? Then you'd just
> drag and drop an MXML file to the browser and it would render?
It is the fact that certain browsers don't support plug-ins that put us in
this situation in the first place.
--
Al
On 2/20/12 4:30 AM, "olegsivo...@gmail.com" wrote:
> Alex, then I have several more questions regarding the framework and
> compiler integration. Previously, no one cared to separate these two
> things, which resulted in that certain features of MXML weren't available
> to non-framework code.
Jeffry, what code shows up in the editor really depends on the editor you
are using, that's not universal, and stuff in mx_internal may show as well,
if you wanted it to. However, Flash Builder also used various metadata to
hide either specific methods or entire classes (usually generated) from
doc
On Mon, Feb 20, 2012 at 4:07 PM, David Arno wrote:
> > From: niel.drumm...@googlemail.com [mailto:niel.drumm...@googlemail.com]
> On Behalf Of Niel Drummond
>
Thank you.
> > Sent: 20 February 2012 07:45
> >
> > 1) Wait for falcon, projected stable release late 2012, early 2013.
> This to my mi
Hi Omar,
On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
wrote:
> ...RSL stands for runtime shared library. Portions of the Flex SDK are
> compiled into .SWZ files that are(were) signed by Adobe. This would yield
> two benefits, 1.) security and 2.) Flash Player RSL caching at a global
> level (al
On 2/20/2012 12:00 PM, Left Right wrote:
I was actually under impression that Adobe will be committing code to
the compiler and / or framework developed here - that was at least my
understanding of the last whitepaper posted by Adobe, or am I
misunderstanding it? Maybe the word "support" isn't
On 20 Feb 2012, at 16:56, Omar Gonzalez wrote:
> 1.) security and 2.) Flash Player RSL caching at a global
> level (all domains),
> Having Apache host RSLs would help us to
> resolve #1 as Adobe will no longer host our RSLs. I hope that's clear and
> that I've gotten that all correct, someone co
On 21/02/2012 01:52, David Francis Buhler wrote:
Google's Dart is gaining traction and is now offered as a browser plug-in
(for Chrome).
[1]
http://news.cnet.com/8301-30685_3-57380050-264/googles-dart-language-arrives-in-chrome-test-version/
There are strong discussions against dart in a release
I was actually under impression that Adobe will be committing code to the
compiler and / or framework developed here - that was at least my
understanding of the last whitepaper posted by Adobe, or am I
misunderstanding it? Maybe the word "support" isn't the best choice though.
In my experience, th
On Mon, Feb 20, 2012 at 8:50 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Mon, Feb 20, 2012 at 1:03 AM, jude wrote:
> > ..In the whitepaper there was mention that Adobe would not be signing the
> > framework RSL compiled by the Apache Flex project. That's a big hit for
> > downloading every time.
Google's Dart is gaining traction and is now offered as a browser plug-in
(for Chrome).
[1]
http://news.cnet.com/8301-30685_3-57380050-264/googles-dart-language-arrives-in-chrome-test-version/
On Mon, Feb 20, 2012 at 4:42 AM, ganaraj p r wrote:
> If browser plugins were a future we would be wo
On Mon, Feb 20, 2012 at 3:05 AM, Rui Silva wrote:
> ...I will not engage in any message thread
> whose tone starts to go south and that decision may prevent me, or others
> who may take the same course of action, to contribute to otherwise
> interesting subjects and initiatives
Way to go, aka
Hi,
On Mon, Feb 20, 2012 at 1:03 AM, jude wrote:
> ..In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?...
I have no idea wha
On 2/20/2012 11:00 AM, Left Right wrote:
I never found any practical use case that justified the use of internal or
custom namespaces
The Flex Framework uses a custom namespace (mx_internal) all over the
place. I believe the use case is "we need to expose this stuff so our
code works, but don
Hello David,
The mxmlc will be the compiler as soon as its commited and stay that way
until another approach is sufficient I suppose.
I think the Falcon as well as gosh are community approach. Like the
various JavaScript engines were for FireFox.
If someone is interested in the development of
Talking about security, I think there is nothing being done to prevent
man-in-the-middle for JS libraries hosted by Google for example, so it does
not seem to be an issue even if JS is plain text and easier to manipulate
(I did not hear about such an attack). Is the RSL issue we are talking
about a
Well, HaXe can use pre-compiled code, since maybe more then a year ago I
guess... It doesn't use SWC, but ans SWF as an input is OK. Probably Niel
can elaborate on that, or correct me if I'm wrong.
HaXe has a way to deal with AS3 global functions (for example you could've
exposed them through Lib
On 20 Feb 2012, at 15:30, Haykel BEN JEMIA wrote:
>> Although: I suspect with effort, it is possible for suitably skilled for
>> man-in-the-middle attacker to intercept the loader SWF and replace the
>> byte-code storing the MD5 values their own and still inject badLibrary.
> What about storing t
Haykel Ben Jemia
Allmas
Web & Mobile Development
http://www.allmas-tn.com
On 20 February 2012 14:52, Paul Evans wrote:
>
> Although: I suspect with effort, it is possible for suitably skilled for
> man-in-the-middle attacker to intercept the loader SWF and replace the
> byte-code storing the
On Feb 20, 2012 7:08 AM, "David Arno" wrote:
>
> > From: niel.drumm...@googlemail.com [mailto:niel.drumm...@googlemail.com]
> On Behalf Of Niel Drummond
> > Sent: 20 February 2012 07:45
> >
> > 1) Wait for falcon, projected stable release late 2012, early 2013.
> This to my mind is the most risky
> From: niel.drumm...@googlemail.com [mailto:niel.drumm...@googlemail.com]
On Behalf Of Niel Drummond
> Sent: 20 February 2012 07:45
>
> 1) Wait for falcon, projected stable release late 2012, early 2013.
This to my mind is the most risky of your three options. We wait a year,
then maybe get a com
Martin, I was studying the PDF (and the sources that Google posted to be
used as examples), I've reached no conclusion so far, but things like the
below make me question the point of the article.
I've started with looking at Java, and here's something I find funny:
public BasicBlock createNode(
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 13:53
>
> Sorry - still thinking up problems rather than solutions.
I think that is the best way with anything to do with security.
David.
On 20 Feb 2012, at 13:19, David Arno wrote:
>> * can i get a badLoader into the application
> Probably. After all, what happens if someone spoofs the apache flex download
> site and provides a dodgy version of the SDK? But that's a whole different
> issue.
Yeah, though signed RSLs currently prot
[
https://issues.apache.org/jira/browse/FLEX-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211842#comment-13211842
]
Marcus Fritze commented on FLEX-16:
---
Just in case, someone need the ZIP-Code RegExp for GB
David,
you just brought up a question in my mind: What if we don't use the
"global index" at runtime but also at compile time:
programmer
-> Defines "RSL" with compile-time swc/f and online path and
eventual failbacks
compiler
-> Creates MD5 from from swc/f
-> Compares
I've been looking to other technologies for the past few months and so
far HaXe was closest to Actionscript I could ever get. Though I'm still
a noob at that language, I felt pretty familiar and comfortable working
with it.
Going with Neil's options:
no.1 is freaking risky, considering what w
On Feb 20, 2012 1:21 PM, "Michael A. Labriola"
wrote:
> I am not going to hold my breath on this, but the way to avoid this would
be to have adobe host a minimal-sized, signed rsl, that contained our
hashes. Then we have the hashes with a level of confidence.
Can't the hashes of all used librarie
[
https://issues.apache.org/jira/browse/FLEX-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211835#comment-13211835
]
Justin Mclean commented on FLEX-16:
---
To make it easier to review here is the list of change
>more specifically... If attacker succeeds in the above, every app that wants
>to use the same library version is compromised by that browser cache even
>after leaving the 'man-in-the-middle' compromised network.
I am not going to hold my breath on this, but the way to avoid this would be to
h
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 12:41
> i don't know enough about security, but in probing for flaws in that idea
I'd approach from:
I don't know much about security either. Thus why I'm questioning whether it
can be done, rather than just s
On 20 Feb 2012, at 12:41, Paul Evans wrote:
> * Can I 'man-in-the-middle' and inject badLibrary with corresponding md5 to
> make it look good - i.e. spoof the central repository
> * can i get a badLoader into the application
more specifically... If attacker succeeds in the above, every app that
Hi,
If any other British or Australia person can review the patches submitted and
comment in JIRA I'm sure that will help the patch to get accepted.
https://issues.apache.org/jira/browse/FLEX-16
If it helps I should be able to generate a difference between the en_AU and
en_US locales.
Thanks,
If going with what Niel described to be the options, I'd certainly stick to
the third one. I like HaXe and had written in it quite a bit. It had proved
to be a much better compiler then whatever Adobe had offered in the past.
It's unreasonable to deny the chance that Falcon will be an entirely
diff
On 20 Feb 2012, at 11:50, David Arno wrote:
> If we generate MD5 hashes for the SDK SWCs,
> then the loader could check those hashes on load. Would that not be secure
> enough, or is there a flaw in that idea?
i don't know enough about security, but in probing for flaws in that idea I'd
approac
Hi,
> Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
> Adobe won't sign them?
We can still use RSLs both framework RSLs and user compiled/non framework RSLs.
Apache framework RSLs will not be cached by the flash player but they can be
cached by the browser (on a dom
Alex, then I have several more questions regarding the framework and
compiler integration. Previously, no one cared to separate these two
things, which resulted in that certain features of MXML weren't available
to non-framework code. For instance, UIDUtils would make dependency to
IUIComponent and
On 20 Feb 2012, at 11:07, Martin Heidegger wrote:
> The Flashplayer does cache swfs if they come from the same domain.
No, the browser caches SWFs, not flash player.
On 20 Feb 2012, at 12:04, Martin Heidegger wrote:
> The flash player caches the signed RSL's differently.
Yes, but flash player
> From: Martin Heidegger [mailto:m...@leichtgewicht.at]
> Sent: 20 February 2012 12:04
>
> The flash player caches the signed RSL's differently. [1]
Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
Adobe won't sign them? So Apache Flex will need to be based on plain,
un
> The flash player caches the signed RSL's differently. [1]
>
> [1] http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
>
> yours
> Martin.
A more up-to-date version
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html
--
Mansour Blanco
Software e
On 20/02/2012 20:50, David Arno wrote:
From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
Sent: 20 February 2012 10:20
From previous discussion, Alex raised concern of potential exposure to a
man-in-the-middle attack - unless we find a way of getting them signed.
Do they really need
On Feb 20, 2012, at 8:45 AM, Niel Drummond wrote:
> Rudeness and frustrations aside, in the light of desiring an
> html/javascript flex SDK and taking into respect the timeline for a flex
> (cross?)-compiler there really is only three options on the table:
>
> 1) Wait for falcon, projected stabl
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 10:20
>
> From previous discussion, Alex raised concern of potential exposure to a
> man-in-the-middle attack - unless we find a way of getting them signed.
Do they really need signing? If we generate MD5 has
Hi John,
> May I suggest that we just commit the GB version with a "best effort"
> format, then go on to look for a all-encompasing solution.
I've submitted an patch for the en_AU locale for the code now in SVN trunk and
it's only very minor changes are required to convert that to en_GB (just th
The Flashplayer does cache swfs if they come from the same domain.
Apache could offer a central library repository that would be much like
Google JavaScript repository. Its not a RLS but could be equally worth
it. However Google's infrastructure (connections, routing, etc.) is
awesome, no idea
Hi,
> From: "Dave Fisher"
> I was looking to say similar. Here is a useful link.
http://producingoss.com/en/setting-tone.html#prevent-rudeness
>
> Regards,
> Dave
I was actually going to respond to David on the weekend with about the same
concerns especially in consideration for all the peop
+1
-Original Message-
From: John Fletcher [mailto:fletch...@gmail.com]
Sent: 20 February 2012 10:41
To: flex-dev@incubator.apache.org
Subject: Re: Other locales for Flex SDK
May I suggest that we just commit the GB version
with a "best effort"
format, then go on to look for a all-encompa
May I suggest that we just commit the GB version with a "best effort"
format, then go on to look for a all-encompasing solution. The fact that no
GB version exists yet is quite incredible.
John
2012/2/14 David Arno
> > From: Justin Mclean [mailto:jus...@classsoftware.com]
> > Sent: 14 February 2
Thanks for the link Paul. Indead this is a big issue and I think it can not
be fixed as only Adobe can create signed RSLs! Let's make them as small as
possible for now.
Haykel
On 20 February 2012 11:20, Paul Evans wrote:
>
> On 20 Feb 2012, at 09:54, David Arno wrote:
>
> > The idea that Hayk
On 20 Feb 2012, at 09:54, David Arno wrote:
> The idea that Haykel was suggesting though would be to avoid serving it from
> individual hosts and to serve it globally instead. That way the browser only
> has to cache it once, not once per domain. There would be cross-domain
> issues, but I thi
> From: Jarosław Szczepankiewicz [mailto:jszczepankiew...@gmail.com]
> Sent: 20 February 2012 09:44
>
> caching the RSL in the browser is already used and ready (as far as
> www server is properly using Etag etc. headers). Apache http is
> caching static resources very well out of the box (at le
Let me rephrase, I mean Firefox Add-on.
On Mon, Feb 20, 2012 at 3:42 AM, ganaraj p r wrote:
> If browser plugins were a future we would be worrying quite a bit about
> releasing Flex 4.7 or Flex 5. The problem is, the most popular plugin in
> the world seems to have a hazy future, which is proba
caching the RSL in the browser is already used and ready (as far as
www server is properly using Etag etc. headers). Apache http is
caching static resources very well out of the box (at least if it is
not in clusters which may broke Etag). The most important result of
the adobe announcement is that
If browser plugins were a future we would be worrying quite a bit about
releasing Flex 4.7 or Flex 5. The problem is, the most popular plugin in
the world seems to have a hazy future, which is probably the reason for all
the discussion about moving away from Flash.
On Mon, Feb 20, 2012 at 9:09 AM
2012/2/20 David Arno :
>> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
>> Sent: 20 February 2012 09:27
>>
>> Is it possible to enhance the preloader to download required RSLs from
>> a central Apache repository or are there any technical or FP security issues
>> that would make this impossibl
> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
> Sent: 20 February 2012 09:27
>
> Is it possible to enhance the preloader to download required RSLs from
> a central Apache repository or are there any technical or FP security issues
> that would make this impossible?
Unless it is technica
Is it possible to enhance the preloader to download required RSLs from a
central Apache repository or are there any technical or FP security issues
that would make this impossible?
Haykel
On 20 February 2012 10:17, Roland Zwaga wrote:
> >
> > In the whitepaper there was mention that Adobe wou
>
> In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?
>
I believe this is impossible, the Flash Player will only cache RSL's t
Long delayed response... Sounds good.
On Tue, Feb 7, 2012 at 4:07 AM, Bertrand Delacretaz
wrote:
> On Mon, Feb 6, 2012 at 7:53 PM, jude wrote:
> > ...We need a wiki that allows people to contribute to it, we need a blog
> > updated so people can stay up to date without being on the mailing list,
The ease of making HTML pages was partly what hooked me so long ago. I
could type something in a text editor and it would show up rendered in the
browser.
What about a browser plug in that would handle .mxml files? Then you'd just
drag and drop an MXML file to the browser and it would render?
Jud
I say we ask Adobe to show us the money! I mean show us the code of Falcon
/ Falcon JS early before it's "officially" released. It will take time to
get up to speed on it and having the code to learn, even before
participating, will help us be ready to go.
2012/2/20 Jarosław Szczepankiewicz
> Ad
1 - 100 of 101 matches
Mail list logo
