incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wienberg <fr...@jangaroo.net>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sun, 02 Dec 2012 14:34:09 GMT
Hi Alex,

perhaps I did not make the point about the output packaging format so clear.
Of course, for compilation reference, an SWC would suffice. But for
Jangaroo, it did not make any sense to use SWC or SWF for packaging, as we
would have needed to implement an additional format. Also, scanning the
"binaries" (here: JavaScript) to find the API would be cumbersome. Instead,
we use ActionScript as the module API description language and reuse the
parser we already have!
Because we want to put everything produces by a module build into a single
"artifact", we use a JAR containing the generated JS files as well as the
ActionScript describing the module API. For details, see the documentation
of the Jangaroo build
process<https://github.com/CoreMedia/jangaroo-tools/wiki/Maven-Build-Process>
.
For Falcon, it may be more natural to output SWCs containing additional
"binaries" (JavaScript), but if your only compile target is JavaScript, it
feels like an unnecessary overhead.
Does that clarify things?

Concerning the point about closed source, yes, I agree that minification /
obfuscation should suffice. After all, that's what the Java community does,
too, since Java byte code can be reverse-engineered too easily.

Greetings,
-Frank-

On Fri, Nov 30, 2012 at 5:38 PM, Alex Harui <aharui@adobe.com> wrote:

> You guys have lost me a bit.
>
> IMO, all I want as output is a series of .JS files (that would later get
> minified by GCC for release builds).  I don't get how the JSEmitter's
> reliance on SWF output constructs like traits would affect the output.
> Seems like you should be able to generate the same thing from the AST.
> Potentially even faster than having to unravel the
> MethodInfo/MethodBodyInfo
> constructs.
>
> I also don't see how the fact that Falcon consumes SWCs in order to resolve
> the symbols at compilation time affects the output either.  And isn't SWC
> consumption all you really need for modular development?  You shouldn't
> need
> the module binaries, the two projects should be sharing a common interface.
> In my mind, modules are separate .js files loaded at different times.  The
> key is if you can minify them without destroying their common interface.
> Someone said you can tune GCC to do that.
>
> Anyway, good point about closed source since all JS is open.  But all
> enterprises moving to JS just be dealing with this some way already right?
> Isn't minification about as good as abc code in the SWF?  You could always
> dump a SWF and get most of the algorithm back.
>
> Or maybe I'm totally missing what you guys are talking about.
>
> -Alex
>
> On 11/30/12 2:27 AM, "Michael Schmalle" <apache@teotigraphix.com> wrote:
>
> > Quoting Frank Wienberg <frank@jangaroo.net>:
> >
> >> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
> >> <apache@teotigraphix.com>wrote:
> >>
> >>> For FalconJS this process is totally bound to SWF format.
> >>>
> >>> This was my point. For any developer to fix bugs here they have to know
> >>> the SWF format. Which I don't.
> >>>
> >>> This is why I propsed another solution using pure AST like Jangaroo
> does.
> >>>
> >>> I am not skilled enough to understand the trade offs currently. But I
> am
> >>> going to try and see if I can create the same JS code using a different
> >>> algorithm.
> >>>
> >>
> >> I guess the trade off is that the AST approach leads to a different
> >> packaging format. For Jangaroo, we use JARs that contain the generated
> JS
> >> code as well as generated AS "API stubs" (under META-INF/joo-api), that
> is
> >> the AS code is reduced to its API, using the "native" keyword. This
> allows
> >> to compile against other modules without having their source code.
> However,
> >> the consequence is that you need a different classpath and custom build
> >> tools: we created a Maven plugin that provides a custom packaging type
> >> currently called "jangaroo" that outputs a JAR in the format described
> >> above.
> >> When the output format is SWC/SWF, you more closely resemble Flash/Flex.
> >> But honestly, unless we transform ActionScript byte code into JavaScript
> >> (or interpret it in JavaScript like in Gordon's approach), we cannot use
> >> any "binary" modules, anyway, but instead all modules have to be
> recompiled
> >> for use with FalconJS, or even worse you need the complete source code
> for
> >> the whole project, which would increase build time and hinder real
> modular
> >> development as well as closed source modules--quite a show stopper for
> an
> >> Enterprise tool!
> >>
> >> -Frank-
> >>
> >
> > Ok, I didn't even think about the recompile. So in my mind, please
> > correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
> > the packaging and organization structure currently. Where you are
> > using a jar as you said. Correct?
> >
> > Since you have so much experience with as->js, what is your opinion on
> > implementation? I'm asking because I might be putting a lot of work
> > into the compiler output and would like to know which direction. Do
> > you see any way of interfacing jangaroo and falcon/falconjs?
> >
> > Do you think offering the straight AST emitter(which would allow
> > granular compiles with native stubs) like yours AND the SWF/SWC option
> > and somehow getting them on the same API is something to consider?
> >
> > As I said earlier, you have some great code, I would love to work
> > together somehow to get a nice application framework our there like
> > Flex ontop of JS and whatever other language we could get to, Android,
> > iOS, whatever.
> >
> > Thanks for all your time Frank!
> >
> > Mike
> >
> >
> >
> >
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

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