[Laszlo-dev] Dynamic libraries

[Oliver Steele]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4002 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050107/d86893ba/attachment.bin