[Laszlo-dev] Dynamic libraries implications
jsundman at laszlosystems.com
Fri Jan 7 09:35:10 PST 2005
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
Where does kranking fit into this new mix?
Any comments welcome.
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.
> Oliver Steele
> Chief Software Architect
> Laszlo Systems, Inc._______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
More information about the Laszlo-dev