[Laszlo-dev] serverless operation

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.
b. The JavaScript API for this.
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.
and optionally:
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 
them.

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

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

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.

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.

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: 4110 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050107/aaa00a3d/attachment.bin