There are no plans at this time to host RSLs somewhere. It might be possible if we get enough support for it. However, they won't be signed and I'm concerned about the security implications of that. I'm not a security expert, but I believe unsigned RSLs will leave you exposed to a man-in-the-middle attack, at that alone might be sufficient to kill any momemtum for a central place to pick up RSLs.
I still hope to make RSLs an unnecessary thing in about two to three years. More on that later after we get a first release out and I get some time to work on it. On 1/5/12 4:30 AM, "Paul Evans" <[email protected]> wrote: > On 5 Jan 2012, at 10:29, [email protected] wrote: > >> On one hand, there is definitely a point for improving the framework's >> modularity and split it in several normal rsl, but from my experience, >> several of the users of applications I've built, especially in the >> corporate/healthcare area, like to clean browser cache at the end of the day >> in an effort to eliminate any history that would reveal where they've been in >> the interewebs. I know this sound stupid, but it happens, so having the >> framework protected in a different cache system would make sense. > > Whether signed or not, or Fp cached or not, will the framework RSLs (release > versions) be hosted on an Apache equivalent to fpdownload.adobe.com/pub/swz... > ? > > If so, that potentially mitigates the case above? An organisation with such a > cache cleaning policy might consider proxy-caching certain domains/resources - > our RSL domain being a prime candidate. > > If not, there's going to be an immediate (network) performance hit for users > of ApacheFlex. > > (not a committer - sorry if this is speaking out of turn) -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
