incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Kwiatkowski <nicho...@spoon.as>
Subject Re: Suggestion: Split Flex SDK into Flex-Core and Flex-More
Date Tue, 10 Jul 2012 11:49:26 GMT
Gary,

Personally, I'm not a big fan of this.  I've seen some other languages do
this, but I've also been stuck in "dependency hell", even for seemingly
core components.  We also have to play the balance game as far as what is
licensed under the Apache License, and what isn't as well (for example, we
wouldn't be able to include code that is not certified as properly licensed
-- meaning code that is not written by contributors).

I like the idea of having a central repository of Flex code, and addons.
 This maybe something that we can post on our wiki or website.  Linking to
them allows people to understand the license model that each of those
components are under which would allow us to host more components (for
example, like the ESRI or IBM component sets).

-Nick

On Tue, Jul 10, 2012 at 4:54 AM, Gary McGhee <subs@buzzware.com.au> wrote:

> In order to free up the Flex SDK to move forward, I'm thinking it would be
> advantageous to split the SDK into "Flex-Core" and "Flex-More" like Merb (a
> Ruby library that merged with Rails).
>
> This would mean that the compiler, standard libraries and core components
> could move forward in versions more freely, eg. without fringe components
> necessarily being updated.
> Also popular third party libraries could more easily be included into
> Flex-More.
>
> When it comes time for FalconJS, it could aim to support just the
> components in Flex-Core to begin with, and projects too could just depend
> on it without Flex-More.
>
> This would be easier to manage too if a package manager became a core
> component as previously suggested, in fact it would make it easy to break
> the SDK into even more chunks.
>
>

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