[Laszlo-dev] serverless operation

[Oliver Steele]

[This message was supposed to follow the set of requirements that I 
spent all day drafting.  But I think I wiped those out, so I'm going to 
go ahead and send this and then get back to work recreating the 
requirements.]

Here's a sketch of some designs for unproxied, or serverless, 
operation.  The goal here is to flush out problems with the 
requirements, and to see if there's something simple we can start with. 
  A large number of more complicated designs are possible to, but I want 
to see if one of these is a useful starting point before I start down 
the path of complexity.

Compilation Switch
An application that is intended for unproxied operation is compiled 
with a compiler switch external to the application sources.  I don't 
want to specify a user interface for this now.  (It might be a 
checkbox, or a button that says "Create unproxied zip", that is 
implemented as a ?lzproxied=false request parameter --- similar to the 
way an application is compiled for debugging via the ?debug=true 
request parameter today.)  In an application that is compiled with this 
mode:
- All data and media requests are unproxied.
- The presence of the <connection> or RPC tag results in a compiler 
warning.
- The presence of e.g. <view resource="http:logo.png"/>, where the 
compiler can easily infer that the value of the resource attribute will 
result in a runtime request for a media type that is not supported in 
an unproxied media request, results in a compiler warning.
- A runtime request for an unsupported service (e.g. 
myView.setResource('http:logo.png')) will result in a debugger warning, 
if debugging is enabled.

Pros:
- A library or application can be compiled for proxied or unproxied 
operation without source changes.
- There's very little to specify (and therefore that there's very 
little to get wrong).
Cons:
- The fact that an application is only  intended for proxied (or for 
unproxied) operation is not documented in the sources; therefore:
- You have to remember to press the correct button when you want to 
test the application in its deployment mode.
- This doesn't support a mixture of proxied and unproxied requests 
within a single application.

Toplevel Attribute
The <canvas> tag has an optional attribute proxied="true|false".  This 
defaults to true, for compatibility with LPS 2.x.  (Default deployment 
mode is actually an issue that is independent of these designs; I'll 
send a separate message about that.)  If proxied="true", all data and 
media requests are proxied (the same as LPS 2.x), and the RPC tags are 
supported.  If proxied="false", data and media requests are unproxied, 
and the compiler performs error detection as in the Compilation Switch  
design, above.

The <library> tag has an optional attribute 
proxied="true|false|inherit".  This defaults to "inherit", which means 
that the library is compiled with the same proxied setting as the 
canvas file that includes it.  It is a compilation error for the 
library tag specifies a proxied value of "true" or "false" and this 
value is different than the (explicit or implicit) proxied value of the 
canvas file that includes it.

In other words, a canvas file may include only library files that have 
the same value for their proxied attribute, or the (default) value of 
"inherit".  You can't mix and match, and the presence of the <library 
proxied> attribute is a way to document to developers and to the 
compiler that a library can only work in one mode of operation.

Pros:
- Only one attribute in the canvas file need be changed to switch 
between proxied and unproxied operation.
- The sources contain machine-readable documentation as to the intended 
deployment mode.
Cons:
- The canvas file has to be edited to switch between proxied and 
unproxied operation.
- This doesn't support a mixture of proxied and unproxied requests 
within a single application.

Compilation Switch + Toplevel Attribute
The <canvas> tag has an optional attribute 
proxied="true|false|inherit", which defaults to "inherit".  If 
proxied="true|false", the application can only be compiled in that 
mode.  (It is an error to provide a request parameter with a different 
compiler setting, and the developer console UI disables options that 
generate this request.)  If proxied="inherit", the application is 
compiled either for proxied or unproxied operation, depending upon the 
value of a compilation switch (which defaults to unproxied).

The behavior for libraries is the same as specified in the Toplevel 
Attribute design.

Pros:
- A library or application can be compiled for proxied or unproxied 
operation without source changes.
- The sources contain machine-readable documentation as to the intended 
deployment mode.
Cons:
- Doesn't support a mixture of proxied and unproxied requests within a 
single application.

Does any of these look like it's on the right track?  Are there cases 
where these obviously wouldn't be sufficient?  (The next step would be 
to write up some use cases, but I'm hoping I can trick people who are 
actually interested in using the feature into writing them for me :-)

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