[Laszlo-dev] Dynamic libraries implications

[John Sundman]

Oliver,

This is very helpful.

I'm wondering about documentation impact.

I expect that the syntax part of snippets will be relatively 
stratightforward (I hope?).  The trickier part will be explaining how 
to structure programs.

Will this be a paragraph's worth of documentation? A Dguide chapter?  A 
separate mini-manual?

Where does kranking fit into this new mix?

Any comments welcome.

jrs

On Jan 7, 2005, at 11:03 AM, Oliver Steele wrote:

> One of the new features for LPS 3.0 is the dynamically loaded library, 
> or dynamic library.  A dynamic library is a library that can be loaded 
> after the main application execution file has loaded.  The initial 
> goal for dynamic libraries is to reduce the initial download size of a 
> Laszlo application, by deferring bandwidth costs until an optional 
> feature of the application is actually used, or at least until the 
> user has had time to interact with the initial screen.  Some non-goals 
> for the initial implementation are shared libraries (where the same 
> dynamically loaded library execution file can be be shared among 
> multiple applications), binary distribution (where a library author 
> can distribute a Laszlo library without distributing source code), and 
> namespaces (where two libraries can define entities with the same 
> name, without collision).  It is intended that the initial version of 
> dynamic libraries be forwards compatible with these features, but, in 
> the interests of implementation time, the initial version will not 
> implement them.
>
> LPS 2.x, for comparison, has static libraries, which use the <library> 
> element to define the library, and the <include> element to include it 
> in an application (or another library).  Static libraries support 
> source code organization, team workflow, and source re-use, but they 
> don't have any effect, versus the alternate strategy of putting 
> everything in one big source file, on the executable file: a program 
> that includes a static library is equivalent, to the compiler, to a 
> program that has had the library source code textually inserted at the 
> point of the <include> element.
>
> Ideally, a dynamic library can contain anything that today's static 
> library contains: class, instance, dataset, resource, and font 
> definitions, as well as <script> blocks.  In practice, the Flash 
> implementation of Laszlo may have some limits which Laszlo inherits 
> from the limits of the Flash file format and execution engine.  We'll 
> be exploring this over the next week; this message is intended partly 
> to set the context for some of the discussions exploring those limits.
>
> I'll send out a concrete proposal for the dynamic library syntax in 
> the coming week.  Henry Minsky is implementing a draft of the syntax, 
> and a limited provisional implementation is available in the 3.0b1 
> release (so you'll be able to try it out as soon as I tell you what it 
> is :-).
>
> Something we haven't decided yet is the name for dynamic libraries.  
> I've been calling them dynamic libraries, short for dynamically loaded 
> libraries, in this message, but that's a provisional name as well.  
> It's unlikely that we'll call them "dynamically loaded libraries 
> (DLL)" because that name has picked up some negative connotations over 
> the past decade.  (These are connotations that I'm now learning to 
> associate with the term "jar file", by the way, but we can get into 
> that separately...)  "Dynamic library" is perhaps more accurate 
> anyway, since it is likely that the location of the library can be 
> determined at runtime, as well as just its bits.  Other names that 
> have been bandied about are "snippets", "runtime libraries", and 
> "runtime loaded libraries".
>
> I suppose one could throw "execution", "late", "lazy", and "deferred" 
> into the mix.  "Deferred" would be consistent with the 
> initstage="deferred" attribute of views and other LZX nodes, which has 
> an analogous function at the instance (as opposed to the file) level.  
> In fact, it might be desireable to allow both "late" libraries which 
> loaded automatically, but after the main execution file has loaded, 
> and "deferred" libraries, which are loaded upon request.
>
> Comments appreciated, although there will be another chance when I 
> post the syntax.
>
> Best,
> Oliver
>
> --
> Oliver Steele
> Chief Software Architect
> Laszlo Systems, Inc._______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev