flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Date Thu, 02 Feb 2017 18:35:45 GMT
I'm going to try to respond to both you and Carlos.

IMO, there are "Application Developers" (AppDevs) and "Component/Framework
Developers" (CompDevs).  Today, in FlexJS, an AppDev can write MXML and AS
and use certain APIs and his/her code will run compile into a SWF or a
pile of JS.

But some CompDev probably needs to write SWF-specific code and/or
JS-specific code.  We have biased the framework to allow CompDevs to go
low-level.  We could have made a different design decision and said to
CompDevs: "you must only use these APIs that we've wrapped around
platform-specific APIs".  But, IMO, that will not result in
high-performance applications and is a real pain for us to support.  For
every one of you who wrote a Flex app and used a flash.*.* class, you
hopefully understand why.  Flex tried to put a layer over Flash so folks
wouldn't have to know flash.*.* APIs, but most of you went low-level
anyway because it was faster or smaller or both.  Or Flex hadn't gotten
around to wrapping some Flash API.  IMO, we are not set up as a community
of volunteers to try to fight that battle.

So, my philosophy is to let CompDevs go low-level in each of their
libraries and as such, there will be platform-specific code in each
library.  But we only have one package (a SWC) for delivering libraries to
AppDevs and CompDevs.

We could make separate SWCs for AppDevs vs CompDevs.  Right now we are
creating a "SWC for SWF" and a "SWC for JS" so we are biased towards
CompDevs.  The AppDevs see lots of non-common APIs in IDE code completion.
 This "dual" compiler change is one solution for AppDevs.  It makes it
easier to compile your app against both platforms and see which APIs you
used that don't exist on one of the target platforms.  That's because we
control the compiler code.

I'm sure we can annotate our classes so IDEs could be smarter about what
code completions to offer, but that requires getting FB, FlashBuilder,
IntelliJ, FlashDevelop, FDT, Moonshine, and VSCode to change.  Only the
last two have active development, so hopefully they will be able to
provide a customer benefit by being smarter.

But even then, I think AppDevs will want to cheat and write
platform-specific code on occasion.

So I keep coming back to the answer that "SWC for SWF" and a "SWC for JS"
per library is the right packaging, but I'm definitely open to other ideas
that we can practically do without abandoning the legacy IDEs.

We can make the compiler smarter.  We can package extra files in SWCs but
the IDEs only expect a single library.swf right now.  We can tweak our
Maven mojos.  We can do more work and deploy "Universal SWCs" (a single
SWC with a library.swf and a js-library.swf) for Maven and VSCode and
Moonshine but deliver "SWCs for JS" for legacy IDEs.  I won't claim to
have the right answer, I just know we have one reasonably good answer now.
 But also remember that any work done in this area has to be traded off
against other work so consider how important improvements here are vs
other things on the to-do list.

Thoughts?
-Alex

On 2/2/17, 9:32 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Hi Alex,
>
>all I’m currently concerned about is that it will be painfull for our
>users. And for us, because as soon as no-brain-developers will start
>using FlexJS, we will probably be swamped with support requests. And I
>remember myself being quite confused about it even now … so I usually try
>to build and if there’s errors I’ll add the second option an try again.
>
>I would definitely not enjoy having to deal with three SWCs per library.
>Ideally we would have only one (That would actually make me
>super-duper-ultra-happy). It would ease up explaining things, it would
>make the Maven plugin a lot simpler and I guess it would reduce
>frustration with early adopters.
>
>If there’s anything I can do to make this happen, just tell me what to do.
>	
>Chris
>
>
>
>Am 02.02.17, 17:38 schrieb "Alex Harui" <aharui@adobe.com>:
>
>    There are already two lib folders (actually three).  Today we have:
>    
>    Frameworks/libs:  XXX.SWC contains:
>        -Flash-based Class Definitions
>        -JS files for JS compiles
>    Frameworks/js/FlexJS/libs:  XXXJS.SWC contains:
>        -JS.swc-based Class Definitions
>    Js/libs:  SWC contains
>        -JS.swc-based Class Definitinons from flex-typedefs
>        -JS files for externs
>    
>    Before I consider this "dual" thing done, I was going to change
>things so
>    there is a copy of the JS files in the XXXJS.swc.  AIUI, Maven has two
>    categories of SWCs: externs and regular, so you can see by packing JS
>    files in the XXXJS.swc it will have the same sort of contents.
>    
>    I have not worked with ANEs, but AIUI, there is one API definition and
>    multiple platform object codes.  For FlexJS SWCs there are different
>API
>    definitions per platform.  IMO, by packing JS files in the SWC we are
>    doing something like what ANE packaging does.  The JS is effectively
>the
>    platform object code.  But all existing IDEs expect only a single
>    library.swf for the API definitions.  We can change that, but then
>every
>    IDE would have to change.  IMO, backward-compatibility is still
>important,
>    not just for FB.  We could still have two SWCs per library and still
>    package a js-library.swf into the SWF SWC if that makes VSCode work
>    better.  We could also make the compiler guess that if there is a
>XXX.SWC
>    to first look for a XXXJS.SWC in another folder.  That would be far
>    simpler, IMO.
>    
>    Could we create a third SWC with only the definitions in common?
>    Probably, but IMO, not critical right now (or at least, that's not
>what I
>    want to do with my time).   The dual compile will effectively show you
>    what is common, and I hope we can add documentation to mark what is
>common.
>    
>    I think there are two pieces here:
>    -Will it be to painful to require third parties to ship two SWCs per
>    library?
>    -Can we make it so that if you specify XXX.SWC on the library path,
>you
>    don't also have to specify XXXJS.SWC in the config?
>    
>    I think we can make the compilers make some assumptions so that if
>there
>    are two SWCs per library the consumer only has to think about one.
>But
>    for backward compatibility, I'd say we still need two SWCs per
>library.
>    
>    Thoughts?
>    -Alex
>    
>    
>    
>    On 2/2/17, 3:10 AM, "carlos.rovira@gmail.com on behalf of Carlos
>Rovira"
>    <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>wrote:
>    
>    >I think self contain is better too. For example Adobe AIR does the
>same
>    >with Multiplatform ANEs. If the ANE is implemented for iOS, Android,
>and
>    >more,...all goes in the same .ane and I think that's really good,
>since
>    >the
>    >library is in fact Multiplatform and ready to use for anyone in
>anyplace
>    >:)
>    >
>    >2017-02-02 10:46 GMT+01:00 Christofer Dutz
><christofer.dutz@c-ware.de>:
>    >
>    >> Would it be somehow possible to make the swcs self-contained?
>    >> Right now they contain catalog.xml and library.swf … couldn’t this
>    >>contain
>    >> something like a “catalog-js.xml” and a “library-js.swf” … this
>way we
>    >> could just add a dependency to a SWC and the compiler could
>internally
>    >>grab
>    >> what he needs. This would the the option which I would prefer most
>…
>    >>sort
>    >> of 1000000000+ ;-)
>    >>
>    >> Chris
>    >>
>    >> Am 02.02.17, 10:27 schrieb "Harbs" <harbs.lists@gmail.com>:
>    >>
>    >>     So there would be two different lib folders? One for swf
>compilation
>    >> and another for js compilation? Maybe a third lib folder for “dual”
>    >> compilation?
>    >>
>    >>     Here’s a thought: Would it be possible to create a “dual” swc
>which
>    >> would contain the definitions for both JS and SWF? And have falcon
>    >> understand how to read the correct one depending on the output?
>    >>
>    >>     > On Feb 2, 2017, at 12:05 AM, Alex Harui <aharui@adobe.com>
>wrote:
>    >>     >
>    >>     >
>    >>     >
>    >>     > On 2/1/17, 1:41 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>    >>     >
>    >>     >> One question: How do you envision swc for third party
>libraries
>    >>if
>    >> both
>    >>     >> JS and SWF swcs are being used?
>    >>     >>
>    >>     >> Is this strictly an SDK thing or would there be some
>mechanism
>    >>for
>    >> having
>    >>     >> split swcs for libs as well?
>    >>     >
>    >>     > I think third-parties will also have to distribute two SWCs
>if
>    >>there
>    >> are
>    >>     > differences in the API surfaces.  If you have a high-level
>library
>    >> that
>    >>     > just talks to downstream libraries and has no COMPILE::
>blocks you
>    >>     > probably only need the one SWC.
>    >>     >
>    >>     > Is this an ok thing to do to our customers?
>    >>     >
>    >>     > -Alex
>    >>     >
>    >>
>    >>
>    >>
>    >>
>    >
>    >
>    >-- 
>    >
>    >Carlos Rovira
>    >Director General
>    >M: +34 607 22 60 05
>    >http://www.codeoscopic.com
>    >http://www.avant2.es
>    >
>    >Este mensaje se dirige exclusivamente a su destinatario y puede
>contener
>    >información privilegiada o confidencial. Si ha recibido este mensaje
>por
>    >error, le rogamos que nos lo comunique inmediatamente por esta misma
>vía y
>    >proceda a su destrucción.
>    >
>    >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>    >comunicamos
>    >que sus datos forman parte de un fichero cuyo responsable es
>CODEOSCOPIC
>    >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>    >servicio o información solicitados, teniendo usted derecho de acceso,
>    >rectificación, cancelación y oposición de sus datos dirigiéndose a
>    >nuestras
>    >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>documentación
>    >necesaria.
>    
>    
>

Mime
View raw message