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. 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? > > >>>HTML.swc: > >>> Window > >>> Event > >>> UIEvent > >>> MouseEvent > >>> HTMLElement > >>> etc. > >>> > >>> > >> See for HTML lib, Roland used WebIDL parser to create it; > >> > >> https://github.com/RandoriAS/randori-libraries/tree/master/HTMLCoreLib > > I couldn’t quickly find the rules around IDL and WebIDL Parser to figure > out if we can do the same. Can you point us to links and licenses? > I need Roland's advice here, I had nothing to do with this part of the project. > > >> > >> > >> Question; So the code style, you said we might use the FlexJS emitter > >>but > >> I don't see how that is possible since it's not a vanilla emitter. > >> > >> It seems to me I need to know the exact code style that a vanilla > >> transpiler will create and I can make that emitter as another backend, > >>what > >> do you think? > >> > >> @Josj you have any thoughts? I am ready to start writing it. :) > > I’m not clear what isn’t vanilla about the current emitter if you are > writing code against these two SWCs. I don’t know how much Google Closure > Library code will actually get sucked in. But it seems reasonable to at > least start with the FlexJS emitter then figure out what needs to change. > 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. 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? Mike > > -Alex > >
