incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Francis Buhler <davidbuh...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Thu, 01 Mar 2012 23:46:51 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message