blueback09 at gmail.com
Fri Nov 25 18:19:21 CET 2016
Thanks for that explanation. I've heard you mention this setup several
times before but this is the most detail I've seen you put in one place.
Clarification question: do you cache the last stacks downloaded in case the
user isn't connected to a network?
On Fri, Nov 25, 2016 at 8:02 AM, Richard Gaskin <ambassador at fourthworld.com>
> Roger Eller wrote:
> > I disagree that you might as well be running a desktop app. The
> > download of the helper would only be necessary once (like the old
> > RevWeb plugin). Back when we had the RevWeb plugin, my browser based
> > apps just worked.
> > Being in a position where localized automation is primarily what I
> > create for in-house users, this would allow me to update/maintain to
> > a single code-source, but without having my hands tied
> > capability-wise by the browser.
> That's exactly where a standalone is every bit as valuable as Mark was
> We need not make every stack file into a standalone for our users to run
> All they need is one copy of the LiveCode engine, with just enough code so
> it knows where to download more stack files.
> Just as a version of the LC engine as a browser plugin can download and
> run stack files, any standalone already installed on the user's machine can
> do the same.
> But like you say, 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.
> Most of my work these days is with "streaming apps" - here's my setup:
> - Standalone
> Contains only enough code to download one stack file from
> our server.
> This is only a little more than:
> go stack "https://somedomain.com/path/to/mainstackfile.livecode"
> ...with some error-checking and one dialog to report errors if
> This standalone is downloaded and installed this only once. We may
> update it once every year or two when we truly need to update the
> LC engine version we're using, but those times are rare.
> Server - Downloads
> - Main Library
> This is the stack file that gets downloaded first. It contains all
> other code and URLs the app will need to download and run other stack
> We can completely change all aspects of the app by changing this one
> stack file on our server at any time.
> - Other stack files, downloaded as needed:
> - login.livecode -- provides a UI for tasks requiring authentication
> - admin.livecode -- UI for admin tasks for those users who've
> authenticated with admin privileges.
> - logs.livecode -- Viewer for server logs to monitor usage and
> provide diagnostics for errors (see below),
> - other stacks -- We can create and upload any task-specific UI
> and/or code as needed, and download-n-run it
> from any other.
> Server - Processing
> - LC standalone or LC Server running as CGI under Apache, providing:
> - data store access through REST API with CRUD operations
> - authentication and other user services
> - logging
> - anything else we need on the server to support user-specific data
> management and sharing of data for collaborative workflows.
> - Upload Tool - automatically saves stack files I'm working on,
> compresses them, and uploads them to their respective
> locations on the server where the client standalone
> will find them.
> Many stack files are so small that the compression
> isn't really necessary, but I'm picky about performance
> and it never hurts to reduce transfer times where that
> can be done as easily as using LC's built-in compress
> and decompress functions.
> 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've had more than a few times when I've been in teleconferences with
> clients where we're discussing new features, and before the meeting is over
> I've already written the code and posted it to the server, and let them
> know that all they have to do to get the new feature is restart the app -
> as close to real-time updates as one could hope for.
> Getting started doesn't require all these parts; 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 use use "go stack..." commands in our posts to this list because
> it really is that easy to use HTTP to deliver stack files.
> Another simple example included with every LC install is LiveNet (formerly
> RevNet), accessible in the IDE from Development -> Plugins -> GoLiveNet.
> That plugin downloads a small stack file which then obtains data and other
> resources from more than a dozen sources around the world, but the user
> never needs to think about any of that because LC makes it so easy for our
> apps to do the downloading for them.
> 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.
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> Ambassador at FourthWorld.com http://www.FourthWorld.com
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode