Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of davidbuhler@gmail.com
 designates 209.85.210.175 as permitted sender)
Received-SPF: pass (google.com: domain of davidbuhler@gmail.com designates
 10.50.236.5 as permitted sender) client-ip=10.50.236.5;
MIME-Version: 1.0
In-Reply-To: 
 <CACK5iZdayrjjAQP3fAd2jW-yx-2hbPDcj24GdX_vBr9Tc_6L2A@mail.gmail.com>
References: 
 <CAEFz_vuNuXuoJ3fMFmfGExutGy4T_8u9bUfBxQBkhsfHmdW9aw@mail.gmail.com>
	<CACK5iZdayrjjAQP3fAd2jW-yx-2hbPDcj24GdX_vBr9Tc_6L2A@mail.gmail.com>
Date: Thu, 1 Mar 2012 18:46:51 -0500
Message-ID: 
 <CAH12+xNFfyQNmh8YOBP1jPV4uSgSNyRRj5B5m+POpnyaw6aEVA@mail.gmail.com>
Subject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
From: David Francis Buhler <davidbuhler@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae934046103d12004ba371351

--14dae934046103d12004ba371351
Content-Type: text/plain; charset=ISO-8859-1

I believe Adobe needed to support a backwards compatible product.

My own preference is to take the same approach as certain software
companies, and leave it to clients and companies to migrate to a faster,
better, leaner platform (because we're not supporting backwards
compatibility).

On Thu, Mar 1, 2012 at 6:25 PM, Om <bigosmallm@gmail.com> wrote:

> On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.developer@gmail.com
> >wrote:
>
> > >
> > > Maybe, I am completely off base here, but exactly what is the
> motivation
> > of
> > > the spark component set?  Is it the new skinning paradigm, or is it
> > better
> > > performing versions of existing components or is it a completely
> > different
> > > set of components that happen to have similar names?  If this is a
> > separate
> > > conversation, please reply in a new thread.
> > >
> > > Thanks,
> > > Om
> > >
> >
> > Personally for me the motivation to create Spark equivalents of some of
> > these components is the better skinning model. At least, in my opinion, I
> > much prefer the Spark skinning over MX. This is why I haven't done any MX
> > apps since Spark came out.
> >
> >
> Right, but why are mx components shipping when equivalent spark versions
> are available?  This to me is the biggest sticking point.  Can we nix mx
> components from future releases if that is the 'old' way of doing things?
>
> Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
> parity before nixing mx in a future release?  If yes, can someone explain
> the motivations for such a decision?
>
> (Non-rhetorical question) Is everyone okay with different components with
> completely different architectures and supporting different sets of
> features with the same names shipping alongside in the same SDK?  If yes,
> what are the benefits?
>
> Or was the original plan was to support two different sets of components
> that support two different skinning architectures?  It does not appear so
> from the code hints (Use s:XYZ instead) that appear when we attempt to use
> an mx component.
>
> IMHO, we need to pick one plan and make sure that EVERY component we ship
> with the SDK follows the same set of rules.
>
> Thanks,
> Om
>

--14dae934046103d12004ba371351--