[Laszlo-dev] serverless operation

[Henry Minsky]

Maybe we could default everything to unproxied, and have a specific
URL protocol that you use when you want to use the LPS server, i.e.,
instead of http:logo.png you say lps:logo.png, (that's ugly, but
something like that).

It would make it explicit which mechanism you want, and there would be
no ambiguity. The disadvantage is that you need to change URLs all
over the place when you want to change the loading mechanism. But I
like it because there is less 'magic' sprinkled around, you can see
what will happen explicitly in each case.


On Tue, 18 Jan 2005 14:25:24 -0500, Oliver Steele
<steele at laszlosystems.com> wrote:
> [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.
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> 
> 
>