Richard, 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 <ambassa...@fourthworld.com> wrote: > 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 > suggesting. > > 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. > > 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: > > > Client > ------ > - 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 > encountered. > > 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 > files. > > 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. > > > > Development > ----------- > - 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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
