Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DDCC19C61 for ; Thu, 5 Jan 2012 10:15:43 +0000 (UTC) Received: (qmail 88783 invoked by uid 500); 5 Jan 2012 10:15:43 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 88648 invoked by uid 500); 5 Jan 2012 10:15:38 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 88640 invoked by uid 99); 5 Jan 2012 10:15:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 10:15:35 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [66.63.181.70] (HELO mail.controlserveronline.com) (66.63.181.70) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 10:15:27 +0000 Received: by mail.controlserveronline.com via HTTP; Thu, 5 Jan 2012 02:29:19 -0800 From: "flex@rduartes.net" To: Subject: Re: Flex Framework rsl's Date: Thu, 5 Jan 2012 02:29:19 -0800 Reply-To: flex@rduartes.net Message-ID: <5fbb91e$6b60d455$68c5be3$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [195.23.102.126] I have mixed feeling about this. On one hand, there is definitely a point for improving the framework's modu= larity and split it in several normal rsl, but from my experience, several = of the users of applications I've built, especially in the corporate/health= care area, like to clean browser cache at the end of the day in an effort t= o eliminate any history that would reveal where they've been in the interew= ebs. I know this sound stupid, but it happens, so having the framework prot= ected in a different cache system would make sense. You could argue that in a medium to large application, the framework should= be that much of a burden to be downloaded with the rest of the application= 's infrastructure, but there is definitely a use case for a protected frame= work cache. I agree with Roland in respect to the fact that Adobe will not easily sign = a framework they're not fully in control. I wish we and they could find som= e sort of workaround for this, but it looks bleak, at best. As I said, mixed feelings. I guess I'll be happy with whichever result come= s out of this, but if there is no workaround for the secure rsl for the fra= mework, I think someone should concentrate on that modularity stuff. Regards, Rui -------- Original Message -------- > From: "Jo=E3o Fernandes" > Sent: quinta-feira, 5 de Janeiro de 2012 10:15 > To: flex-dev@incubator.apache.org > Subject: Re: Flex Framework rsl's > > I could live without signed RSLs and just use plain swf RSLs. Of course > there is a nice benefit having them on FP cache but is it a crucial > feature? Couldn't the SDK somehow be enhanced so we wouldn't even need it > anymore? > > Jo=E3o Fernandes