As explained in the System Administrator's Guide to Deploying OpenLaszlo Applications, deploying proxied OpenLaszlo applications requires that you install a J2EE application server or servlet container. OpenLaszlo comes with the Tomcat servlet container included, but, depending on how you have access to the web, it may not be practical or even possible for you to use this to make your applications generally available. So, before you decide to start development of an OpenLaszlo application for, say, a hobby website, you should find out whether your ISP provides the capability for you to install a servlet container. If this is not practical for you, you can still develop and deploy SOLO applications.

Access to the OpenLaszlo Server is required for certain run-time features, such as SOAP and XML-RPC requests, and for processing certain types of media files.

Here is a list of features that require OpenLaszlo Server:

If your application relies on any of these features, you cannot deploy it SOLO.

In addition, there are differences between how proxied and SOLO applications handle some kinds of XML data and http responses. See below.

If either deployment manner is available to you, the decision may come down to which works better. You should do test deployments under each method and see which gives the faster performance.

By default, the OpenLaszlo proxy server ships "wide open", which can be a security hazard. See the System Administrator's Guide to Deploying OpenLaszlo Applications, for a discussion of OpenLaszlo security management.

If an application is compiled for proxied operation, all data and media requests are proxied and the remote procedure calls (RPC) tags are supported.

If the canvas contains the proxied="false" attribute, that means the application will be deployed SOLO. Data and media requests are unproxied, and the compiler performs error detection:

2.5.2. Whitespace, namespace and http response header considerations

When loading data, SOLO applications do not provide a way to access http headers.

Also note that the client system not provide any useful error messages when your data has problems in it, whereas the OpenLaszlo Server can provide clues to what's going on. This another reason why it's best to first develop and test your programs as proxied applications, and then make them SOLO.

It does cost more in terms of CPU time to strip namespace prefixes (you control this with the nsprefix attribute on <dataset> ) , and it costs more to trim whitespace.

The current defaults are:

nsprefix = false (namespace prefixes are stripped)
trimwhitespace = false (leading and trailing whitespace is preserved in text
nodes)

For security (to prevent malicious use), the Flash player (for applications compiled to SWF) or the browser (for applications compiled to DHTML) requires that programs demonstrate that they have permission to access any files that they reference. Depending on where the data originates and whether your application is compiled to SWF or DHTML, you have various options for doing this this.

For instance, say you have an OpenLaszlo application that uses art assets from a remote source:

<resource name="prettypicture" src="http://someURL/picture.gif">

where someURL is different from where the application is served. In applications compiled to SWF, the file can be accessed if a crossdomain policy is in effect. Applications compiled to DHTML cannot access the file.

Applications that are proxied do not have this problem, since the OpenLaszlo server proxies all requests, and therefore from the point of view of the application on the client, all data is coming from the same place.

3.1.1. Crossdomain.xml policy

SWF only: The features described in this section only work in applications compiled to SWF. They do not work in applications compiled to other runtimes.

Flash requires that a properly configured crossdomain.xml file be present at the top level of that domain to give you permission to access the file. For complete instructions on how to do this, see the Macromedia documentation. A representative example follows here.

The Flash security model is tricky, and several different issues may come into play when deploying an OpenLaszlo application that accesses data from a separate server, even if it resides on the same host. For OpenLaszlo applications that will be deployed as SOLO SWF, you can add a crossdomain.xml file to the server, as follows:

1. put a crossdomain.xml on the data server with this code:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Using 'domain="*"' is very liberal; it gives access to this file to any program. you can tighten the settings to be more specific to the OpenLaslzo application.

2. put this code in your OpenLaszlo application:

<script>
System.security.loadPolicyFile("http://localhost:8888/[server]/crossdomain.xml");
</script>

Where "server" is the name of the directory in which the crossdomain file resides.

Note also that some versions of browsers do not recognize the crossdomain.xml file when asked to do POST requests, but do recognize it for querystrings. If this situation arises, the user will have to upgrade to an accomodating browser in order to make POSTs.

3.1.2. Restrictions on DHTML

DHTML only: The features described in this section only work in applications compiled to DHTML. They do not work in applications compiled to other runtimes.

In SOLO applications compiled to DHTML, the application and the data do not originate at the same URL, the data load will fail. This is a consequence of the XMLHTTPRequest() object, which enforces this policy. There are browser-specific workarounds to this problem, but they are nonstandard and not recommended.

If the file is coming from the same server as the application, you can use Firefox's LiveHTTPHeaders to monitor what actual request is being made to the server, this is often instructive.

The development process for serverless applications is a simple variation on the usual Laszlo cycle:

Compiling dir/canvas.lzx creates the file dir/canvas.lzx.swf.

4.0.3#/bin

        lzc filename.lzx 

        filename.swf

You can specify deployment by using:

Requesting a SOLO application /path/to/canvas.lzx has the side effect of creating a file /path/to/canvas.lzx.swf. This file, or the directory that contains this file, can be copied to the htdoc directory of a server that doesn't include the Openlaszlo Server.

The file is called canvas.lzx.swf instead of canvas.swf to preserve OpenLaszlo "branding"—just as the presence of .php or .jsp in a URL is good for the awareness of PHP and Java, even though .htaccess can be configured not to require this filename extensions in the URL. This also makes it less likely that compiling an application (for example, logo.lzx) will overwrite a file that it includes (if logo.lzx includes logo.swf).

The file is placed in the same directory as the source file so that relative references to datasets and media requests will work.

{|
! lzproxied query parameter
!	<canvas proxied=>
!	result
|-
| not present ||	not present ||	proxied
|-
| not present ||	inherit	 || proxied
|-
| not present ||	true ||	proxied
|-
| not present ||	false ||	unproxied
|-
| true	|| not present ||	proxied
|-
| true ||	inherit ||	proxied
|-
| true ||	true ||	proxied
|-
| true ||	false ||	error
|-
| false ||	not present ||	unproxied
|-
| false ||	inherit ||	unproxied
|-
| false ||	true ||	error
|-
| false ||	false ||	unproxied
|}

lzEmbed({url: 'main.lzx.swf?'+window.location.search.substring(1), bgcolor: '#ffffff', width: '100%', height: '100%'});

These programs create applications that use the OpenLaszlo Server to proxy the dataset request:

 
  <canvas proxied="true">
    <datasource name="ds" src="http:data.xml" request="true"/>
    <text datapath="ds:/root/text()"/>
  </canvas>

 
  <canvas proxied="true">
    <include href="lib-ds-proxied.lzx"/>
  </canvas>

   
  <canvas proxied="true">
    <include href="lib-ds-default.lzx"/>
  </canvas>

Compiler errors are returned for these cases:

A proxied canvas that includes an unproxied library:

  
  <canvas proxied="true">
    <!--Error:proxied canvas that includes an unproxied library:-->
    <include href="lib-ds-unproxied.lzx"/>
  </canvas>

A unproxied canvas that includes a proxied library:

  <canvas proxied="false">
    <!--Error:A serverless canvas that includes a proxied library-->
    <include href="lib-ds-proxied.lzx"/>
  </canvas>

Media requests use the global canvas attribute.

These programs make media requests through the server:

  
  <canvas proxied="true">
    <view src="http:logo.jpg"/>
  </canvas>

  
  <canvas proxied="inherit">
    <view src="http:logo.jpg"/>
  </canvas>

This example shows a data request that is mediated by the OpenLaszlo Server:

  
  <canvas>
    <view src="http:logo.jpg"/>
  </canvas>

This program makes a direct (serverless) media request:

  
  <canvas proxied="false">
    <view src="http:logo.jpg"/>
  </canvas>

It's possible to write proxies and transcoders in other languages, so you only really need the OpenLaszlo server if you want to dynamically compile OpenLaszlo programs on the fly. Python, Ruby, Java and PHP all work well for writing proxies and transcoders, depending on the kind of data formats you need to work with. Of course, using the OpenLaszlo Server is easier then writing your own from scratch, but if you need to do so, there is nothing in the OpenLaszlo architecture that prevents that.

The OpenLaszlo source code depends on a bunch of stand-alone Java libraries for manipulating Flash files, XML and images, which (if you're using Java) you could use in your own applications without incorporating the entire OpenLaszlo server.

One thing the OpenLaszlo server does that you can implement in other ways is transcoding media. Different versions of the Flash player only support certain types of media, so if you want to load a gif image from another server whose content you don't have control over (for example, a gif thumbnail of a person from a social networking site), then you need a server somewhere to transcode it from gif to something the flash player can read like SWF or PNG. A lot of scripting languages support the "ming" dynamic SWF generation toolkit, and there are other libraries like Python's "flashticle" for reading and writing Flash content on the fly (including swf and flv).

Another service provided by the OpenLaszlo server is performing SOAP and XML/RPC requests on behalf of the OpenLaszlo client. It's easiest to use ReST instead of SOAP and XML/RPC, since it's so much less complicated and lets you tailor the XML for your particular application (simplifying the XML to make data binding to visual OpenLaszlo classes more direct, resulting in less processing and simpler code on the client). But if there's an existing SOAP or ReST service you have to use, then you can write a proxy on the server to translate between simple ReST requests from OpenLaszlo to more complex remote procedure calls. This lets you do some processing and filtering and multiple requests on the server side (where the network's lightning fast), so you can have a more efficient client/server protocol (because that goes through skinny pipes to the client, so it should be optimized, where remote procedure calls from server to server across the backbone can send lots of fluffy data quickly and don't need to be boiled down to the bare essentials).

A great example of this philosophy in action is the Cooqy OpenLaszlo interface to eBay, which lets you browse eBay efficiently over a low-bandwidth dial-up line. The Cooqy server talks to the eBay web API, and boils it down to the essential results to display in the OpenLaszlo client, which downloads XML and images incrementally and starts displaying results immediately. So the client/server protocol between the client and Cooqy is extremely efficient, while the server/server protocol between Cooqy and eBay runs between fast servers over the internet backbone.

You can see the Cooqy program in action here.

Rich object oriented interfaces like the eBay web service API aren't always the right level of abstraction for the most efficient client/server communication. So there are some good reasons to make a proxy server that boils everything down to your own application specific XML format, instead of trying to mash together a whole bunch of complex general purpose APIs in the client. Cooqy does a great job of distributing the processing and network load so it works well over a low speed network connection, so it's much more efficient that the equivalent html pages. Plus it doesn't hurt that the entire Cooqy application is smaller than eBay's html home page!

The other issue you have to deal with are the security restrictions on the Flash player downloading XML and SWF files from other servers than the one it's running from. The remote server you want to download XML from must give you permission with a crossdomain.xml file. If you need to download swf or XML from a server that doesn't give the Flash player permission with a crossdomain.xml file, then that's another reason you might want to have a proxy running on your own server.

And of course there are always unfortunate browser bugs that may force you to use a proxy. Internet Explorer has a bug that makes it impossible to download compressed content into plug-ins like Flash, which you can work around with a proxy.

For example, the first version of Don Hopkin's YouTube player in OpenLaszlo had the Flash player directly download the YouTube text HTML web page for the video, and then it parsed out the url of the FLV file from the web page so it could play it directly. Unfortunately that only worked in Firefox because of a bug in Internet Explorer not delivering compressed text content to plug-ins (and YouTube gzip compresses their web pages). To solve this problem a proxy on the server was written to perform the screen scraping.

You can run the YouTube player here:

http://www.donhopkins.com/trunk/demos/youtube/youtube.lzx?lzt=swf

This is the youtubeplayer component source, and its supporting lzx files:

http://www.donhopkins.com/trunk/demos/youtube/youtubeplayer.lzx?lzt=source http://www.donhopkins.com/trunk/demos/youtube/youtube.lzx?lzt=source http://www.donhopkins.com/trunk/demos/youtube/videolibraryicon.lzx?lzt=source http://www.donhopkins.com/trunk/demos/youtube/videolibrarypopup.lzx?lzt=source

Here's the source of the YouTube proxy in Java, as a JSP. We've copied it to another file and added the .txt extension so you can look at the source instead of executing it.

http://www.DonHopkins.com/trunk/demos/youtube/youtube.jsp.txt

It performs a ReST call on the YouTube API to perform searches (which only returns the id of the video and the URL of the HTML web page the view the video, but not the actual url of the FLV video file). When the user plays the video, it performs another call to download the web pages of the video, and scrape out the URL of the FLV file from each one.

The youtube proxy supports the following functions:

videoGetFlvUrl(id) http://www.DonHopkins.com/trunk/demos/youtube/youtube.jsp?method=videoGetFlvUrl&id=SRCux7wefH0

videosListFeatured() http://www.DonHopkins.com/trunk/demos/youtube/youtube.jsp?method=videosListFeatured

videosListByTag(tag) // comma separated tags http://www.DonHopkins.com/trunk/demos/youtube/youtube.jsp?method=videosListByTag&tag=kitten,cute

videosListByUser(user) http://www.DonHopkins.com/trunk/demos/youtube/youtube.jsp?method=videosListByUser&user=marccanter