[Laszlo-dev] Dynamic libraries

[Oliver Steele]

It's been pointed out that this design for dynamic libraries may be 
impossible to implement in some runtimes, such as JVM or CLR.  It may 
also not be necessary in other runtimes, since the initial download 
size of an application is of most concern when it's a consumer-facing 
web application embedded in a web page on the open web.  This use case 
will typically use the Flash runtime anyway, at least for the immediate 
future.

So: The spec for dynamic libraries (once it exists) should specify that 
they are optional, and that the syntax for specifying that a library is 
dynamic may be ignored.

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