Re: WSAPI replacement draft

[Chris Babcock <cbabcock@...>]

Warning: Long, hypothetical, web app oriented and not at all specific
to Lua. (I'm fine with follow up going off-list, too.)

On Sat, Jan 22, 2011 at 7:14 PM, Matthew Frazier
<leafstormrush@gmail.com> wrote:
>
>> The biggest thing I see going for the spec is the ability for the
>> application to communicate about its state mechanisms to the server.
>
> Sorry, but I'm not sure I quite get what you're talking about here. Could
> you elaborate a bit?

Sorry, that was two steps removed from the document and a little
backwards. I got interrupted between two thoughts and you got half of
each.

What you do have, in the environment table, is a way for the
application to know what modes the server supports for connection
state, which implies that an application may automatically configure
itself. When you use any of the current crop of web servers or
frameworks, you configure one or more mount points and restart the
server to have the new settings take effect. Your application is
either written to use a given interface or it uses some kind of common
library to provide deployment options. This initializes an application
differently depending on how it's invoked. If it happens that the
application logic doesn't hold up to the invocation method used then
it either crashes or runs with unreliable results until it is
reconfigured. A LASI web application could try a concurrency or
persistence mode offered by the server and fall back back to a safer
operating mode if errors were reported, e.g "The application isn't
thread safe after all," or "There's a memory leak or data leak so stop
running it persistently."

It also happens that a traditional web application doesn't share state
information easily with other instances of itself, so requiring
different mount points for CGI-like operation and for persistent
operation of different application components doesn't happen. If a web
app could able to use a single LASI server to do fine grained traffic
shaping based on application level logic and replace complicated
deployments that currently use different web servers for different
components of the application, that's would be a compelling use case.
While it's fairly common to use a media server to offload bandwidth
from the main server, there's more that could be done to optimize
traffic in a web application that just isn't done because it's too
difficult with the current crop of web servers. While introducing a
new syntax - no matter how easy to learn - will be a hard sell to
existing web developers, the ability to have your media, application
code and data API all running efficiently from a single URL without
using a proxy would be a killer feature.

In other words, the server environment table could be the key to a
server implementation that provides an alternative to XSS hacks, uses
application data to prefetch media to cache and automatically
optimizes rich web applications for the run-time environment, because
it will no longer be necessary to tie operation of a web application
to a single model of operation. I don't think that it's practical for
an application to switch an established connection from an OS thread
to a coroutine without dropping the connection, but a new connection
is a low price to switch from a light concurrency model to a heavy one
(or visa versa) to optimize memory or throughput for the current
operation. Current implementations require a new connection anyways -
on one side of the proxy or the other unless the cache hits.

LASI seems to me to be better targeted as a light web framework
specification than as a heavy web server spec. It could run on top of
an ultralight web server that provides run-time selectable concurrency
models and configurable buffer sizes while leaving all the
abstractions to the framework. Maybe even run LASI on top of WSAPI for
development and testing then use the test data to configure the
stripped-out server for optimal performance in the production
environment.

Chris
--
51st century guy