[Laszlo-dev] serverless operation
steele at laszlosystems.com
Tue Jan 18 14:56:30 PST 2005
I'd like to float a set of requirements for serverless, or unproxied,
operation. Have at it; also, this is (or will become) the set of
requirements that designs for serverless should be evaluated against.
The problem that unproxied operation is intended to solve is that
deploying a Laszlo application to the client, currently requires
deploying the LPS servlet on the server. Requiring the LPS servlet
during deployment is a problem because:
- A particular server may not be running Java. This is the case for
many ISPs, for example.
- A particular server's servlet container may not be qualified against
the LPS jar. Today, this is the case with JRun (which currently has
class loader conflicts).
- It is more difficult for a development organization to qualify a
server+client-application, than to qualify a client application alone.
There are simply more moving parts.
- Deploying a server is riskier than deploying a client-only
application, because server failure modes affect more users
- Lastly, the presence of a server component creates a perceived
capacity issue. This has never been a problem in practice (e.g. Yahoo,
Earthlink), and there is a scalability whitepaper with metrics that
demonstrate scalability, but these don't address the initial
This feature must allow deployment of the largest possible set of
Laszlo applications --- within the constraints of implementation time
and capabilities of the execution environment --- without an instance
of LPS running on the server (e.g. served from an instance of Apache).
An example of an implementation time constraint is SOAP: no one is
currently signed up for a client-only implementation of SOAP (the
current implementation relies on server transcoding), and we wouldn't
hold the initial delivery of unproxied operation for that feature. An
example of an execution environment constraint is support for
runtime-requested PNGs. The Flash players don't support PNG as an
image format, so this can't be supported without server-side
It should be possible to use the same source files to create either
proxied or unproxied executable files. This is important for two
reasons. First, the decision about whether to deploy an application
proxied or unproxied may happen late in the development process,
possibly following performance measurement on the two modes of
operation for that particular application. It is desirable to minimize
the number of edits that is necessary to measure these modes operation,
and to change the deployment mode. Second, it is desirable to share
libraries between applications that are designed for proxied operation,
and applications that are designed for unproxied operation. To the
extent that these libraries can operate in either mode, it is desirable
to make them usable, without source modifications, in either kind of
It is not a goal of this message to separate the Flash-specific and the
Flash-independent portions of the Laszlo specification in general.
(That's a separate project.) This message does distinguish between the
requirements for any Laszlo implementation, and the requirements for
the (existing) Flash Laszlo implementation, but this is just to avoid
introducing any additional gratuitous challenges to the task of
implementing an alternate runtime with this feature.
Flash Laszlo is the implementation of the Laszlo platform for the Flash
An execution engine (aka execution environment, or virtual machine) is
a software component that instantiates and executes a Laszlo
application. The Flash player is execution engine for Flash Laszlo.
A executable file (or executable) is the initial input to an execution
engine, and encapsulates the execution-time information about the
Laszlo application. The executable file for a Laszlo application
compiled with LPS 2.x is swf5 file, and the executable file for an
application compiled with LPS 3.0 is swf6 or swf7.
An application instance (or instance, where this is unambiguous) is a
particular instance, invocation, or execution of a Laszlo application
on a particular client node. If a browser has two tabs that are open
to the same HTML page, and this page embeds a Laszlo application, there
is one execution engine executing one executable, but there are two
A data request is a execution-time request for a dataset. The
<dataset> and <datasource> tags and the LzDatasource.doRequest() method
create data requests.
A media request is an execution-time request for a media file: an
image, animation, audio file, or movie. The <view resource> attribute
and the LzView.setSource() and LzView.setResource() attributes create
An rpc request is a JavaRPC, XML-RPC, or SOAP request.
A request is a data, media, or rpc request.
A proxied request is a request that is mediated by an instance of the
LPS servlet. The servlet proxies the HTTP request to the endpoint that
is named in the request URL, and proxies the result (possibly with
caching and transcoding) back to the application instance. An unproxied
request is a request that is sent directly from the application
instance to the endpoint..
A proxied application instance (or proxied instance) is an application
instance that has access to an instance of the LPS servlet. For
practical purposes, this means it was served from an instance of a
servlet container that contains the LPS servlet. This is the mode of
operation that is supported today.
An unproxied application instance (or unproxied instance) is an
application instance that does not have access to an LPS servlet
instance; for example, if it was served via Apache.
Running as a proxied application instance, or an unproxied application
instance, are the two modes of operation for an LPS application.
A declarative swf file is a swf file (swf3, swf4, swf5, or swf6) that
contains no ActionScript except STOP and PLAY.
Note that it is logically possible for proxied instance to make both
proxied and unproxied requests. An unproxied instance may only make
unproxied requests, because by definition there is no server-side
instance that could perform the proxying.
Here's a first cut; speak up if you think something should be elevated,
or isn't necessary. MAY, MUST, and SHOULD are defined as in
- MUST means a design goes back to the drawing board if it doesn't
satisfy this requirement.
- SHOULD is a tie-breaker between designs that satisfy MUST
- MAY is optional but desirable. It's optional either because it's
less important than SHOULD; or because it's known to be unimplementable
on some execution environments but may be intended to be supported on
GR1. Except where otherwise specified, all documented features should
have the same API and behavior in proxied and unproxied mode of
GR2. All documented features SHOULD have the same API and behavior in
LPS 2.x, and in proxied operation in LPS 3.0.
GR3. All documented features SHOULD have the same API and behavior in
LPS 2.x, and in the default operation mode in LPS 3.0. (If the default
operation mode is proxied, GR2 and GR3 are the same.)
Syntax and warnings:
S1. It SHOULD be possible to specify that an application or library is
only intended for proxied deployment.
S2. It SHOULD be possible to specify that an application or library is
only intended for unproxied deployment.
E1. Compile of an application that uses proxied-only features, to an
unproxied executable, SHOULD result in compilation warnings.
E2. Unproxied execution of an application that uses proxied-only SHOULD
result in visible warnings (e.g. the debugger, or a dialog box).
DR1. It MUST be possible for an unproxied instance to make unproxied
DR2. It MAY be possible for a proxied instance to make unproxied data
DR3. It SHOULD be possible to use the same source to make unproxied
data requests from an unproxied instance, and proxied data requests
from a proxied instance.
DR4. [I had something here about acceptencodings and cacheable that I
don't have the heart to figure out again, but I think some of this
stuff becomes optional.]
MR1. It MUST be possible for an unproxied instance to make unproxied
media requests for media types in the set of unproxied media types
MR2. It MAY be possible for a proxied instance to make unproxied media
MR3. It SHOULD be possible to use the same source to make unproxied
media requests from an unproxied instance, and proxied media requests
from a proxied instance.
MR4. It MAY be possible to use the same source to make media requests
from an proxied instance, that are unproxied iff they are in the
unproxied media request set and proxied otherwise.
MS1. The set of unproxied media requests SHOULD include a lossless
compression format; e.g. PNG or GIF. (This is MAY because the Flash
runtime doesn't support it, so requiring it would shoot down the whole
MS2. The set of unproxied media requests MUST include a lossy
compression format; e.g. JPEG.
MS3. The set of unproxied media requests MUST include a vector graphics
format; e.g. declarative swf, or SVG [TBD: minimal profile]
MS4. The set of unproxied media requests SHOULD include a vector
animation format; e.g. declarative swf.
MS5. The set of unproxied media requests SHOULD include a video format;
MS6. The set of unproxied media requests SHOULD include an audio
format; e.g. MP3.
FMS1. The set of unproxied media requests for Flash Laszlo MUST include
FMS2. The set of unproxied media requests for Flash Laszlo MUST include
FMS3. The set of unproxied media requests for Flash Laszlo SHOULD
FMS4. The set of unproxied media requests for Flash Laszlo MUST include
MP3, subject to the restrictions listed in the Laszlo Developers Guide.
RPC1. JavaRPC SHOULD NOT be supported in an unproxied instance.
Rationale: If LPS isn't running on the server anyway, we should
encourage use of a standards-body standard instead.
RPC2. XML-RPC MAY be supported in an unproxied instance. (The initial
implementation for unproxied operation for Flash Laszlo is unlikely to
RPC3. SOAP MAY be supported in an unproxied instance. (The initial
implementation for unproxied operation for Flash Laszlo is unlikely to
RPC4. The <connection> tag MAY be supported in an unproxied instance.
(LPS 3.0 will not support this, but we could document the protocol so
that this is possible.)
Chief Software Architect
Laszlo Systems, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 11364 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050118/9b36360e/attachment-0001.bin
More information about the Laszlo-dev