[Laszlo-dev] serverless operation

Henry Minsky henry.minsky at gmail.com
Mon Jan 3 11:27:49 PST 2005


Actually it turns out that  loading XML directly using the Flash
loader/parser is asynchronous, it was the LFC code we were running
after the onload event to convert the Flash XML object into
LzDataElement that was occupying the player.


On Mon, 3 Jan 2005 14:17:25 -0500, Oliver Steele
<steele at laszlosystems.com> wrote:
> [Here's my attempt just to see if I understand the lay of the land.
> I'll give some naming suggestions next.]
> 
> In LPS 2.x, the Laszlo server is used during deployment mode to handle
> these types of requests:
> * Application requests (cached, and gzipped), from the browser
> (typically via an HTML <embed>).  The server responds with the
> application binary executable (swf).
> * Media requests (cached, proxied, transcoded).  The server transcodes
> media files (JPEG, PNG, mp3) to a format that the Flash 5 player can
> present.
> * Data requests (cached, proxied, transcoded).  The server compiles XML
> files to a format (ActionScript bytecodes) that the Flash 5 player can
> efficiently parse.
> * SOAP and XML-RPC requests (proxied, transcoded).  The client doesn't
> actually use SOAP-XML and XML-RPC as the wire format.
> * JavaRPC requests.  The endpoints of these requests are methods on the
> server.
> 
> The Laszlo server does three things to data and media requests:
> * Proxying.  The client communicates directly with the server, and
> indirectly with the named endpoint of the request.  This replaces Flash
> security limitations with a more configurable set of deployer-specified
> limitations (controlled by an auditable XML file).
> * Transcoding.  The server transcodes media and data into a format that
> the Flash runtime can present (for media), or efficiently parse (for
> data).  It transcodes SOAP and XML-RPC requests into SOAP-XML and
> serialized XML-RPC.
> * Caching.  The server optionally caches media and data, in addition to
> (or instead of) any client-side caching.
> 
> Even today, the Laszlo server isn't actually required to service
> application requests.  This mode of operation isn't supported in LPS
> 2.x, but it has always been possible to compile a Laszlo application to
> a swf file, and serve this swf file from a web server such as Apache or
> IIS that doesn't embed the Laszlo server.  The problem is that the only
> kind of application that can be served this way is one that doesn't
> make any media or data requests during its execution --- this is
> probably a pretty small subset of the set of interesting Laszlo
> applications.
> 
> The goal for LPS 3.0 is to increase the set of Laszlo applications that
> can be served from a web server that doesn't include the Laszlo
> servlet.  We have been planning to do this by disintermediating the
> server from media requests and data requests.  This is possible because
> the Flash 6 and greater players can display a wider set of media types,
> and because using the Flash 6 client-side XML parser is comparable in
> speed to using the compiled binary XML format that the Laszlo server
> creates.  These capabilities of Flash 6 make the server less necessary
> for transcoding.  An application may still require proxying or caching
> services from the server, but these are easier to re-implement in
> another server environment (such as Apache) --- the spec for these
> services isn't Laszlo-specific or Flash-specific, the way that the
> transcoding capabilities are.
> 
> There will still be (as of the LPS 3.0 release) benefits of running the
> Laszlo server:
> * The Laszlo server still transcodes more media types than Flash player
> can render.
> * Transcoded XML requests load asynchronously; it appears that the
> Flash native XML parser is synchronous, which can tie up a program's UI
> when a large dataset comes in.
> * LPS 3.0 won't support client-only SOAP or XML-RPC, so you'll still
> need the server to use SOAP or XML-RPC web services --- only XML over
> HTTP will work without a server.  (This isn't a fundamental limitation,
> but nobody has signed up to implement client-only SOAP or XML-RPC
> files, or to integrate a library that has a suitable open-source
> license.)
> * The Laszlo server can cache and proxy media and data requests.  If
> you aren't using the Laszlo server, but you need caching or proxying,
> then you need to implement this in your own server and in your
> application source code --- for example, change <view
> src="http://othersite.com/image.jpg"/> to <view
> src="http://mysite.com/proxy.php&url=http://othersite.com/image.jpg"/>.
> 
> 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
> 
> 
>


More information about the Laszlo-dev mailing list