[Laszlo-dev] serverless operation

[Oliver Steele]

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.

Problem
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 
concurrently.
- 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 
perception.

Goals
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 
transcoding.

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 
application.

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.

Definitions
Flash Laszlo is the implementation of the Laszlo platform for the Flash 
player.
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 
application instances.
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 
media requests.
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.

Requirements
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 
<http://www.faqs.org/rfcs/rfc2119.html>.  Informally:
- 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 
requirements.
- 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 
others.

General requirements:
GR1. Except where otherwise specified, all documented features should 
have the same API and behavior in proxied and unproxied mode of 
operation.
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.)
GR4.

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).

Data requests:
DR1. It MUST be possible for an unproxied instance to make unproxied 
data requests.
DR2. It MAY be possible for a proxied instance to make unproxied data 
requests.
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.]

Media requests:
MR1. It MUST be possible for an unproxied instance to make unproxied 
media requests for media types in the set of unproxied media types 
(below).
MR2. It MAY be possible for a proxied instance to make unproxied media 
requests.
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 
feature :-(
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; 
e.g. H.263.
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 
JPEG.
FMS2. The set of unproxied media requests for Flash Laszlo MUST include 
declarative swf.
FMS3. The set of unproxied media requests for Flash Laszlo SHOULD 
include H.263.
FMS4. The set of unproxied media requests for Flash Laszlo MUST include 
MP3, subject to the restrictions listed in the Laszlo Developers Guide.

RPC requests:
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 
support this.)
RPC3. SOAP MAY be supported in an unproxied instance.  (The initial 
implementation for unproxied operation for Flash Laszlo is unlikely to 
support this.)
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.)

Bombs away!

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: 11364 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050118/9b36360e/attachment-0001.bin