[Laszlo-dev] dynamic libraries and resources

[P T Withington]

On 13 Feb 2005, at 09:38, Oliver Steele wrote:

> This sounds reasonable for an initial implementation.  It won't work 
> for separate compilation units or shared libraries, but as long as the 
> API is forwards compatible with those, that's not an issue.  I'll 
> continue to work on specs for those (they're not 3.0 features) so that 
> we can verify that the syntax is indeed forwards compatible.

Do we _need_ separate compilation units?  Since one goal of an LZX app 
is client performance, expending extra CPU cycles doing whole-program 
compilation (and optimization) is worthwhile.  Saving CPU cycles by 
having separate compilation units seems unnecessary.

> I doubt the spec does this yet, but the intent is that it's up to the 
> implementation as to the relation between the <import> statement and 
> load units anyway --- that <import> can include files at compile time 
> the same as <include>, and still be conforming.  This is almost the 
> same as saying that loading is part of the pragmatics, not the 
> semantics, except that you can still write a program that behaves 
> differently depending on when a library is loaded (by testing for the 
> presence of entities defined in the library), so the spec needs to 
> actually say that the semantics is unspecified.

Do we really want the developer to be surprised like that?  The whole 
point of Eric's proposal is to eliminate surprise.  Rather than the 
compiler magically changing a resource from being compiled in to 
dynamically loaded, the developer explicitly asks for one or the other. 
  I would think, for client performance reasons, the developer would 
similarly want to explicitly say whether a library is compiled in or 
loaded at runtime.

Did I imagine it, or was there some talk of not having separate include 
and import tags and instead having a single tag with a modifier that 
said when to load it?

> On Feb 11, 2005, at 6:51 PM, Eric Bloch wrote:
>
>> Hey Folks,
>>
>> We're still having some discussion about how best to implement this 
>> given the constraints of the Flash runtime.  I'm going to summarize 
>> our latest thoughts.  Please chime in if you have any suggestions or 
>> if you think I've misrepresented latest thinking.
>>
>> As an aside, this isn't ideal, but it appears practical and useful 
>> still.
>>
>>
>> 1) When compiling to the Flash runtime, the LZX compiler will compile 
>> in all resources that are declared inside a dynamically loaded 
>> library into the including application.
>>
>> 2) If you would like resources to be loaded at runtime in a 
>> dynamically loadable library, you need to have a source url for them 
>> and use LzView.setSource().
>>
>> 3) We want to include some more LZX syntax and LFC apis to allow one 
>> to specify a multi-frame resource who's individual frames are 
>> loadable dynamically.  This is not currently planned for 3.0.
>>
>> 4) In order to speed up application startup time, it is possible that 
>> the LZX compiler will move the inclusion of resources from 
>> dynamically loadable libraries into ImportAsset tags at the end of 
>> the application.  We need to play with this some to understand how 
>> this interacts with other HTTP transactions that would occur during 
>> application load time.
>>
>> FYI, the justification for (1) is that, while the compiler could 
>> generate some code in your app to dynamically load resources for you, 
>> these would have to be treated, in a Flash runtime, differently than 
>> resources that come in during the initial application load (no 
>> clone/copying; pardon my Flash-speak there as I don't know the right 
>> movieclip apis to which I should refer).  Given that the choice 
>> between "compiled in" and "dynamically loaded" would need to be under 
>> the developer's control, we decided to stick with our existing 
>> system/semantics/apis since they're easy to understand and explain 
>> and any other syntax we'd add to allow someone to control this could 
>> make things even more confusing.
>>
>> Fwiw, this is a specification of behavior for the Flash runtime; 
>> dynamically loadable libraries implemented under a more sane-runtime 
>> would likely have better semantics.
>>
>> -Eric
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev