I wanted to capture this so it’s easy to refer to.

Richard Gaskin, the Livecode community manager, has this explanation of how he deploys his applications to users.

We need not make every stack file into a standalone for our users to run it.

All they need is one copy of the LiveCode engine, with just enough code so it knows where to download more stack files…any standalone already installed on the user’s machine can [download and run stack files]…a standalone engine isn’t limited to the confines of the browser, and devs deploying with a standalone never need to think about how to handle UI elements never intended for their app, like how to handle the browser’s Back button.

In addition to providing a better user experience through a UI dedicated to the tasks your app supports, “streaming stacks” can be safer too: with the relatively recent addition of the securityPermissions global property, it’s possible to deliver standalones that download and run stacks that are safer than nearly any browser.

Richard goes on to describe his setup:

on the client

1. standalone (downloaded and installed only once – only updated when the LC engine needs an update)
   1. go stack “https://somedomain.com/path/to/mainstackfile.livecode”
   2. error-checking
   3. a dialog to report errors

on the server

1. client-facing
   1. main library (can change all aspects of the app by changing this file on the server at any time)
      1. gets downloaded to client first
      2. contains all other code and URLs to download and run other stack files
   2. other stack files
      1. login.livecode (UI for tasks requiring authentication)
      2. admin.livecode (UI for admin tasks for those who authenticate as admin)
      3. logs.livecode (UI for server logs)
      4. other stacks (can download and run these from any other stack)
2. developer-facing
   1. LiveCode standalone or LC server running as CGI under Apache
      1. data store access through REST API with CRUD operations
      2. authentication and other user services
      3. logging
      4. anything else (user-specific data mgmt., sharing for collaborative workflow, etc)
   2. upload tool
      1. automatically saves stack files
      2. compress & upload to server where client standalone will find them

This setup lets us enhance and refine all aspects of the system at any time, and the user never needs to update the standalone they’ve installed.  They just launch the app and since everything we write comes from the server they always have the latest build. I started out with just one standalone downloading one stack file, and added other capabilities as I went along.

In fact, as things progress I’m making more use of substacks within the main downloaded stack file.  This makes things easier for me to build and keep track of, and since we don’t use a lot of heavy media files like full-screeen raster images, the most complex UI I manage (which has dozens of substacks) compresses down to only 648k and flies over even a modest DSL connection in just a couple seconds.

Many of us use “go stack…” commands in our posts to this list because it really is that easy to use HTTP to deliver stack files.

I can’t say enough good things about LC’s ability to run downloaded stacks.  It’s one of the most powerful features in the engine, and perhaps the most under-appreciated.

It’s nearly everything you want with browser-based delivery, but able to handle app designs that go far beyond the browser, with richer features and optionally greater security as well.

Where I use “streaming apps” the requirements are often very similar to what we need from web apps, involving lots of data communication with the server.  If we don’t have a connection there’s little meaningful work that these apps can do, so I haven’t bothered with an offline mode for them. I do, however, have a data cache for one of these apps.  That one’s a CMS for specialized medical content, and the time our editors can spend on a document can be long, often spanning many days.  To ensure the content isn’t lost between sessions we use a check-out/check-in system in which the checked-out document is stored in a local cache until it’s checked back in and safely confirmed on the server.

I could extend the cache subsystem to handle stacks as well, but thus far I haven’t needed it.

Tip:  if you need to cache stacks you can make that super-easy by accompanying each stack file on the server with a small manifest-like text file that contains the build number of the most recently-posted stack.  So on the server you might have something like:

somestack.livecode
somestack.info

…where the *.info file contains essential metadata.

With that you can quickly compare the version/build number of a local stack file (stored in a custom property; I tend to use “ufwVersion” but the key could be any memorable string) with what’s on the server with a super-fast download of that small text file.

I use a simple metadata file for the auto-update feature in my devolution plugin and some of my apps:
<http://fourthworld.com/products/devolution/index.html>

While most of my stuff includes a human-optimized version number for the About box, I generally maintain an integer build numbers so version comparisons are dirt simple.

Even simpler:  you can have your uploading or standalone manager auto-increment your build number whenever you post, so you set it up once and never need to think about it again.