flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 19:43:52 GMT
Thanks, that helps!  I believe you when you say that the overhead is going
to be low.  That is what I care about.


On Wed, Aug 15, 2012 at 12:34 PM, Alex Harui <aharui@adobe.com> wrote:

> > 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.
> Falcon is only tied to the Flex framework because the current code took the
> approach of trying to generate the same sdk-version-dependent generated
> code
> that MXMLC does today.  MXMLC could also be changed to generate something
> less version-dependent.
> >
> > 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?
> If you switch out MXMLC for Falcon and all mustella tests pass, you are
> good
> to go.
> >
> > 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.
> I don't follow your logic.  Your installer is not in the sdk tree but you
> are certainly able to work on it.
> >
> > 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?
> Falcon compiles out to a set of jars just like modules does today.  There
> is
> little overhead.
> > No one has proposed a workflow to working with Falcon as a top-level
> > project yet.
> That's because the way it was worked on in Adobe will be different than the
> way it is worked on in Apache.  As with all prior donations, the goal was
> to
> get it donated.  We should put it in a folder structure that denotes a
> desired configuration (separate from the SDK) and then we'll adjust build
> scripts and documentation to make a good workflow.  I have no idea how
> folks
> are going to want to test their changes to Falcon.  For me, I had some
> simple test files and simply called the MXMLC script equivalents instead.
> Others are going to want to use FB.  We'll get that figured out after
> donation.
> >
> > 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?
> >
> I don't believe I said it was confusing.  I think if the long term goal is
> separation, we should organize it like that from the beginning so we don't
> accidentally lean on something we shouldn't.
> IMO, you should not need a whole branch of the SDK just to run Falcon's
> AS-only capabilities.
> Yes, technically we could work in either folder structure, but I think you
> are the only one currently arguing to put it in modules so I think the tree
> Carol proposed will happen regardless of if you are convinced or not.
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui

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