incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: Falcon location
Date Wed, 15 Aug 2012 19:31:54 GMT
Falcon is tied to the SDK, the text components in the SDK are tied to TLF, the networking classes
in the SDK are clients of BlazeDS, etc. Flex is an ecosystem that all works together and you
can't just mix-and-match any version of one part with any version of another part.

But I now agree with Alex and others that the various subparts need to be able to evolve independently
rather than all being in a single trunk.

So that means we need some way of tying them all together in order to test, or in order to
produce a "here's everything you need" release, and I don't think we're clear on how that
might work. But I'm sure we can figure something out.

- Gordon


-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Wednesday, August 15, 2012 12:19 PM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon location

On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez
<omarg.developer@gmail.com>wrote:

> >
> > IMO, you are arguing against the principle of modularity and/or
> separation
> > of concerns.  Yes, there is a bit more overhead, but is should be 
> > worth
> it.
> > You voted for a much more complex branching strategy supposedly in 
> > favor
> of
> > modularity.  I'm surprised you are pushing back on it here.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
> This ^^^.
>
> -omar
>

I am sorry if I sound like I dont support modularity.   But that is not
what I am saying here.  By Gordon's (who is probably the only person on this list who knows
the Falcon codebase) own admission, Falcon is tied closely to the Flex framework because of
the semantics of MXML.  I agree that this is not a good thing. I agree that this should be
changed.

But, until that level of separation is achieved, how can I as a developer make sure that Falcon
works with the current sdk that I want to ship in the next release?

I keep seeing the word 'eventually'.  All I am saying is, in that eventual case, lets make
Falcon a top level project.  There is nothing preventing anyone from modularizing and separating
the concerns of Falcon while still under modules/falcon.  But the other way round, making
Falcon a top level project prevents me from working with it in the short term.

Alex:
> Yes, there is a bit more overhead, but is should be worth it.
>

How do we know if it is worth it if we don't know what exactly the overhead is?  No one has
proposed a workflow to working with Falcon as a top-level project yet.

Whereas, I am proposing a workflow which is to keep Falcon under modules and create a separate
branch where this would be the main feature.  Anyone who wants to work with Falcon can simply
switch to that feature branch.
Convince me why this is not a better idea.  The only reason against it so far is: "it will
be confusing".  Why is this confusing?

Thanks,
Om

Mime
View raw message