flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: Current compiler question
Date Sat, 17 Nov 2012 18:51:16 GMT
I understand and I agree. I was just reacting to an email by Gordon
explaining that MXML 'coverage' in Falcon is at 80%, but that the last 20%
will take many man-months to finish, something Gordon on his own is
obviously not capable of contributing. And then there's FalconJS, which
from the few things I was able to find with a little help from Google, is
awesome, but only a research project. That means that it has the promise to
be great, but also that it will require a lot of work to get done.

Now, I'm not (very) impatient, so if you can only get into details after
the donation clears, I understand, but meanwhile the conversation seem to
be about re-writing this and using that, anything but what we actually have
available at the moment. I was looking at our resources and thinking about
alternatives… and thought we should consider this as an option, or at least
discuss using what we have and know to work.


On Sat, Nov 17, 2012 at 5:02 PM, Alex Harui <aharui@adobe.com> wrote:

> On 11/17/12 4:47 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
> > As a complete compiler noob, but can somebody answer this:
> >
> > Can we not build a 'mxmlcJS'? I understand that Falcon was specifically
> > designed to have a 'variable backend' that allows for FalconJS to be
> hooked
> > in. Is something like that feasible with the 'previous generation'
> > compiler(s)?
> >
> > The advantage would be that we have a fully fledged MXML/AS compiler that
> > works with the current framework, so no need to rewrite the framework,
> nor
> > invest heavily in finishing the remaining 20% of the Falcon MXML parsing
> > and finish FalconJS. We would 'only' have to rewrite the part of the
> > compiler that currently outputs 'abc' and the browser side player
> > (HTML/CSS/JS) :-)
> >
> > Thoughts?
> >
> In theory, Falcon should also be faster.  And, IMO, the code is cleaner and
> has fewer SDK dependencies which will be to our advantage when trying to
> get
> to other targets.
> -
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

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