On 5/27/15, 1:13 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:

>On Wed, May 27, 2015 at 4:02 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>> This is where, for Apache projects, it gets tricky/messy.  Tamarin code
>>is
>> MPL (or xGPL) and Apache doesn’t like have source code dependencies on
>> those licenses.  You can have a dependency on compiled MPL code so if
>> there was a swc in a stable place that contained those compiled Tamarin
>> .as files then we’d be good to go.  Otherwise, we may need to get an
>> exception or get Adobe to re-license.  Not sure how hard that will be.
>> And just linking to Randori may be seen as a valid way to get around it
>> either since the Randori folks are also Flex committers.
>>
>
>
>Ok, well I emailed Roland and asked if he could enlighten me it's been so
>long, I feel dumb when talking about Randori.

Hey, can you email Roland about AS3Commons’ ZIP library?  We use that in
the Installer and I think it needs to be moved someplace more stable like
GitHub because the old links to it stopped working.

>
>We did not have playerglobal.swc and used FalconJX so it has to work and
>if
>the wheel has already been created, I see no reason in reinventing it, we
>would just use built, could I for instance as a separate entity "fork"
>that
>repo to mine and then I maintain the code and compile it if wee need to,
>then get the swc from my repo?
>

I would want to get a ruling on that from higher up in Apache.  First
there is the risk that your site goes away some day.  Then there is the
question as to whether PMC folks can set up external entities to get
around some of these Apache rules.  Now if there was already a swc we
could use on the mozilla site then that would be usable.

>
>
>Hmm, ok maybe it's me being numb, I guess I am confusing the MXMLEmitter
>with the JSEmitter. and what it's doing.
>
>I swear I looked at the JSEmitter and it had a bunch of GCC stuff in it
>and
>all the comments and such. If I was to maintain a straight transpiler I
>would want it to be as clean and extensible as possible.

You are right.  I think if you look in the code for JSFlexJSEmitter you
will find a bunch of GCL stuff and we use GCC to minify the results.  But
from memory (so I could be completely wrong) the GCL stuff is used for
goog.requires to load other dependencies, goog.inherits and goog.base
(sort of) to deal with inheritance.  But if you have a class that extends
from Object that is just creating HTMLElements and listening for mouse
clicks, I’m not sure how much “goog” will be in the output.

>
>On that note; In the Randori emitter I used about 8 class compositions in
>the JS emitter whcih decoupled a huge amount of code. I think we could do
>that with the current GFLexJS emitter and share 1/2 to 2/3 of the code
>base
>that exists right now.
>
>What do you think?

Not sure I understood that, but I trust you.  Sharing code is almost
always good.

-Alex

Reply via email to