[Laszlo-dev] serverless operation
steele at laszlosystems.com
Fri Jan 7 15:03:38 PST 2005
Some more notes:
The design for serverless operation needs to cover:
a. The xml syntax for specifying whether a data or media request is
direct or proxied.
c. A convenient way to declare that an entire application is direct,
that doesn't depend on editing each data or media request.
d. The failure mode when a feature that can only be supported by the
Laszlo server is used without one.
e. The interaction with dynamic libraries.
f. Specifying a proxy host that is different from the application
server (Eric's message; also implicit in Cortlandt Winters' use case).
I'm not going to consider (e) any more for now. There's just too many
moving parts; we need to pin each of them down some before we combine
The provisional implementation for (a) is transport="direct|proxied" on
dataset. Adam suggested overloading the cache argument
LzMakeLoad.setSource for (b), and adding <canvas serverless="true"> for
One issue is what the feature should be called. We need at least two
names: for a request that uses the Laszlo server, and a request that
doesn't. There could be a third category of requests: those that use
the Laszlo server if it is necessary, but doesn't otherwise; for
example, to request jpg files directly, but ask for transcoding for png
files. And a fourth category: those that use the Laszlo server if it
is available and not otherwise, to take advantage of the server caching
that the LPS server provides. Both of these are significant feature
creep; and I suggest we not do them, but I wanted to point them out as
not on the map for this implementation and also to see if anyone had a
compelling use case for them.
The naming issue is complicated by the facts that (1) these
applications will be deployed from a web (and possibly an application)
server anyway, so "serverless" isn't technically correct; (2) the
Laszlo server is implemented as a J2EE servlet, so "servletless" is
arguably more correct; and (3) the features that the server provides
are transcoding, proxying, security, and caching, so it's not
completely obvious that the feature can be named by the absence or
presence of any one these features.
Another issue is whether the same application source should be capable
of both server and serverless deployment, without modification to the
sources. One implementation is that the Laszlo server deploys an
application with a parameter that tells it that it was deployed from a
server, and the runtime uses this to figure out which kind of request
to issue. This loses an opportunity to remove unused code (which we
won't take for the initial release anyway), but it simplifies
compilation and deployment.
Another issue is the default canvas-wide setting. Using runtime
detection instead would simplify this question (although then the
compiler couldn't warn about server-mode-only APIs --- but the runtime
could issue debugger warnings).
Another issue is whether (a-b) are necessary. Maybe it's enough to
specify either that all requests use the Laszlo server, or that none
If (a-b) are necessary, then they should use the same name as (c). For
example, <dataset transport="direct"> for a single request and <canvas
transport="direct"> for the canvas; or alternatively <dataset
proxy="none"> and <canvas proxy="none">, but not some mix.
Some attribute names. I've extended each to show how it might satisfy
(f) too; this looks particularly ugly with the last two.
My favorites, by far, are connection, followed by proxy.
After we lock the names down at least temporarily, I'd like to use them
to try out the syntax on some use cases and make sure the cases are (1)
covered and (2) comprehensible.
Chief Software Architect
Laszlo Systems, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 4110 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050107/aaa00a3d/attachment.bin
More information about the Laszlo-dev