Hi Alex,
you're right, maybe this deserves more thinking,...in the actual approach,
I think that compiler should copy the same assets folder to target so SWF
can access it right?

2018-02-28 18:13 GMT+01:00 Alex Harui <[email protected]>:

> We could do that if we get enough complaints, but the nice thing about the
> way it currently works is that the output folder is all-inclusive.  You
> can deploy (after a Maven build) the target/javascript/bin/js-release
> folder and your assets will be in there, and the URLs will be
> URL("assets/MyAsset.jpg").  In your proposal, the user has to remember to
> copy the assets folder as well, and the URLs will look like
> URL("../../../../assets/MyAsset.jpg") and the layout on the web server
> will have to have the same deep folder structure.
>
> Are you seeing long build times?  We could just choose to not overwrite
> existing files.  That might save time.
>
> My 2 cents,
> -Alex
>
> On 2/28/18, 8:40 AM, "[email protected] on behalf of Carlos Rovira"
> <[email protected] on behalf of [email protected]> wrote:
>
> >Hi, don't know if I understand right since all the things about the
> >compiler are beyond my scope, but what I'm suggesting is to realocate
> >resources. But don't know if this sounds crazy or not. In this way we can
> >support current outputs (JS and SWF) but prepare for future outputs
> >(WEBASM, iOS, Android,...)
> >
> >so it will end as is:
> >
> >
> >target
> >  |
> >  ------ assets (inside this folder all output like css, svg, png,...)
> >  |
> >  ------- swf (in this folder the .swf (s) app + modules, but for this all
> >should search for resources in "../assets" for all assets not @Embeded in
> >swf
> >  |
> >  ------- js (in this folder will go html and all js files that again
> >should look for resources in  "../assets"
> >  |
> >  -------- webasm
> >  |
> >  -------- iOS
> >  |
> >  --------  Android
> >  |
> >  --------  whatever other output we want to implement
> >
> >if not I understand that each output should provide its own assets folder,
> >and this will end wasting resources for duplication (n times depending on
> >how many outputs we want to get) and wasting time and CPU process..
> >
> >does this make sense?
> >
> >
> >
> >
> >
> >
> >
> >
> >2018-02-27 18:11 GMT+01:00 Alex Harui <[email protected]>:
> >
> >> Hi Jason,
> >>
> >> Actually, I didn't know that.  I'm not a compiler guy.  Someone else
> >>wrote
> >> the key pieces.  I could see that way back, a compiler might have
> >>written
> >> out intermediate information for the next step, like having a separate
> >> linker that links the object files.  But I don't think I've seen (or
> >>maybe
> >> I just haven't used) options to output extra information for
> >> post-processing after the final output.  We could certainly output extra
> >> information, but then that information needs to be parsed again to be
> >>used
> >> by the publisher.
> >>
> >> If that's the way folks want to go, all we need is a volunteer to make
> >>it
> >> happen.  Currently, the publisher does not need the AST so it might even
> >> be possible to write the publisher in ActionScript.  But that might make
> >> it harder to integrate with Maven.
> >>
> >> What do others think?
> >> -Alex
> >>
> >> On 2/27/18, 8:54 AM, "Jason Guild" <[email protected]> wrote:
> >>
> >> >Alex:
> >> >
> >> >As you probably know, compilers in the old days were implemented in a
> >> >series of stages as separate processes due to memory size limitations.
> >> >The output from the previous stage was fed to the next stage as
> >> >compilation proceeded until object files were produced.
> >> >
> >> >Maybe it makes sense for the compiler to output everything the
> >>publisher
> >> >needs (final ASTs and/or other metadata, etc) when it exits.
> >> >Then a separate publisher process could optionally use that output to
> >>do
> >> >all the expected publish-type things without being intermingled with
> >>the
> >> >compiler itself.
> >> >
> >> >The publisher would probably be simpler to understand on its own and
> >> >maybe more people could be involved with it.
> >> >
> >> >Jason
> >> >
> >> >On 2/26/2018 8:49 PM, Alex Harui wrote:
> >> >> The only
> >> >> downside I've thought of is just that it is weird to have a publisher
> >> >> attached to the compiler.  I don't think most compilers have a
> >> >>publisher.
> >> >
> >> >--
> >> >Jason Guild
> >> >Analyst/Programmer V
> >> >State of Alaska - Department of Transportation & Public Facilities
> >> >Information Systems and Services Division
> >> >820 E. 15th Ave.
> >> >Anchorage, Alaska 99501
> >> >
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C3da558b1a44a46dfc41b08d5
> >7ec9fc08%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554328342487363&s
> >data=aduUVLnj5Q8FYqR9KJ6WZeEoLN1GqSVVbalBmhAwZSA%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to