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
