Thanks, that helps! I believe you when you say that the overhead is going to be low. That is what I care about.
Regards, Om On Wed, Aug 15, 2012 at 12:34 PM, Alex Harui <aha...@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 > >
