On 3/15/13 11:54 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>> My personal goals:
>> 1) For the year: get a major Adobe customer to buy into using this
>> technology. This helps ensure I can continue to work on it full time. I
>> will shift my priorities in order to grab such a customer. For example
>> today I am enhancing HTTPService because a potential customer is interested.
>> 2) For next month: get data-binding {} syntax to work
>> 3) For the month after that: finish CSS to JS
>> 4) For next quarter: Try to port something like "old FlexStore"
>> 5) Also for next quarter: Cut an official release (alpha-level)
>> 6) Continously: get more people to try it and get involved.
>
> Alex, this has me a bit concerned. There is no way I can keep up with
> you in my spare time, if you continue to keep working in FalconJS full
> time. If I don't keep up with you, the switch to FalconJx will become
> more and more difficult. Having looked into the soul of FalconJS the
> past weeks, I agree with Mike and others that it doesn't look like the
> way forward for AS -> JS. Also, with FalconJx we can offer future
> users (customers?) options - VanillaSDK, AMD, FlexJS, the new FXG
> stuff I don't understand the first thing about - something that I'm
> sure will help "sell" Apache Flex to them. And one cross-compiler to
> rule them all will focus this community and give it a sense of
> direction.
>
> So... can we convince you to make the move to FalconJx a priority?
> Moving FlexJS over will mean that we all cooperate on the same
> codebase, something I'm sure will help your cause along much more
> efficient than keeping up the fragmented approach we have right now.
> With the move behind us, I would be very willing to make your goals my
> own as I believe your involvement is crucial for the continued success
> of the project.
>
As soon as we get out of this Git transition and you check in even a partial
implementation of MXML handling, I plan to get FalconJX and take a closer
look.
My understanding is that it is still based on Falcon and uses the futures
mechanism to compile compilation units. I am assuming it has not changed
the notion of "subcompilers". There are different "subcompilers" for
different kinds of file types: FXG, CSS, SWC, MXML, AS. Mike and you
reworked the AS "subcompiler". You are working on the MXML subcompiler. #3
in the list above involves working with the CSS sub-compiler. Om may be
working with the FXG subcompiler. These things should generally "just work"
with FalconJX.
The databinding stuff appears to be a bunch of classes in the MXML
subcompiler and more classes elsewhere. For me, I want to understand how it
works in classic Falcon so I can understand how we're going to deal with it
in both the AS side and JS side of FlexJS. And once I figure it out, I hope
I can just copy the implementation in FalconJX.
It is true that the CSS subcompiler uses the BURM, but it works for FlexJS
and I don't know if we are in any hurry to change that. Do we have to
un-BURM FalconJX or can we just not use the BURM for AS/MXML? BTW, the JS
output for CSS is actually just going to be text/css so I might just pass
over the BURM on the JS/JX but I don't know if it is worth re-coding the AS
side just to un-BURM it. At least not right away.
I have to keep doing my work in FalconJS until you are mostly ready with
MXML in FalconJX because I am feeling lots of pressure to establish FlexJS
ASAP. I am currently trying to sell one internal team at Adobe on it. If I
had waited for FalconJX I would not be able to demo what I can today. And I
don't believe that any of the work I am doing is wasted. FalconJS is not
the competition, it is just a stop-gap place for me to experiment until
FalconJX catches up.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
