Date: Mon, 20 Apr 2015 10:59:58 -0700
From: Richard Gaskin
To: How to use LiveCode <use-livecode@lists.runrev.com
Subject: Re: Stacks and livecode server?
Message-ID: <55353E9E.5090805@fourthworld.
Content-Type: text/plain; charset=utf-8; format=flowed
Eric A. Engle wrote:
> There was a revolution plug in which allowed stacks to be served (I
> believe as “revlets”). I know that has been cancelled, at least for
> now.
Probably forever. Browser plugins were a popular solution in the ’90s,
but became untenable by the turn of the century. Beyond the
incompatible implementations of the various plugin specs browser vendors
provide, there’s the bigger issue: it still requires the user to
download and install a form of the LiveCode engine.
If you’re going to ask users to do that you can just as easily deliver a
standalone that downloads stacks; more easily, actually.
It’s as easy to do in LiveCode as:
go url “http://somedomain/mystack.
A standalone provides the same benefit an any other client software
using Web protocols, such as a browser, in having code and content
centrally located and always up to date. But a LiveCode standalone
offers some advantages difficult or impossible to achieve in a Web browser:
Using a standalone can be far more flexible than using the now-defunct
browser plugin because it doesn’t attempt to cram the user experience
into the confines of a browser window, which is designed for a much more
general task flow. So you never need to deal with questions like “What
happens when the user presses the Back button?” In a standalone,
everything in the UI is dedicated for the task you’re supporting.
A standalone can also be more secure. Mark Waddingham’s addition of the
securityPermissions global property offers reasonably fine-grained
control of what a standalone can and can’t do; turning off all options
except Internet access can deliver a Web-savvy experience safer than
nearly any browser.
Using a standalone is of course dependent on users who value your app
enough to download it. But the same would be true of a browser plugin,
so in terms of that one requirement it’s a wash, and in all other
respects the standalone offers many favorable advantages.
Plus it’s dirt-simple to make today using the LiveCode we have in hand
right now. A majority of the projects I’m working on at the moment are
standalones that download stacks – depending on what your app does and
the needs of its audience, it can be an excellent delivery solution.
> Meanwhile, I have installed livecode for cgi, which and it works.
> I searched the internet to see if the livecode server can be used
> to serve stacks somehow, or is basically only useful for cgi.
> Surprisingly, I didn’t find anything, or at least nothing useful.
It may be less surprising when we consider the different roles of client
and server, and how each differs from other.
In essence, a Web server is just a file server. You request things from
it, and in most cases all it does is find a file at the location
specified in the request, reads it from the server’s disk, and sends
that data over the wire to the client.
Good Web servers are also extensible, so that in addition to serving
static files they can also generate data dynamically on the server and
send that back to the requesting client.
On the client side, what the client software can do with the data it
receives from the server is limited to the engine used. For example, a
mail client can handle email data but little else, and a Web browser
client can handle Web pages and little else.
If you want to deliver LiveCode stack files, you need some form of the
LiveCode on the client machine which can read those.
Web browsers have no understanding of LiveCode files, so if you want to
render the contents of a LiveCode stack within a Web browser you’ll need
to translate it into the form browsers use, HTML for content and
JavaScript for interactivity.
RunRev Ltd. is working on a toolkit that will provide that translation
for us, but it’s likely months away from a preview build and I’d guess
much longer before a final build is available.
So for now, if we want to deliver LiveCode stacks to a client, that
client must be made with LiveCode.
Keep in mind that delivering LiveCode stacks from a Web server doesn’t
require LiveCode Server at all. Useful as it is for other things,
whether or not you use LiveCode Server or any other server-side software
to help generate data doesn’t affect how the client works with that data.
So if your goal is to deliver LiveCode stacks, those are just files on a
server and Apache can do that for you very easily without you needing to
do anything more than just copying the stack to your server. Whenever
any client requests any file from the server, as long as that file
exists the server can read it and send it back, whether it’s an HTML
page, a JPEG image, or a LiveCode stack file.
This is why you won’t find info on using LiveCode Server to deliver
stack files, it just isn’t needed.
Where LiveCode Server can be useful is when the data you want to deliver
needs to be unique for the request.
For example, if you just want to get a JPEG image and it’s always the
same image every time it’s requested, you don’t need to do anything more
than just put the image file on the server and you’re done. But if you
wanted to allow the user to customize the image, as in making a postcard
with a customized greeting, then you’d need something more than just a
file server, something that can add the desired greeting text to the
image and export the result to send back to the client. For things like
that a CGI app like LiveCode Server is great, adding custom programming
to augment the simple file serving Web servers do by default.
When using LiveCode Server, the client can be whatever software can
handle the data you’re sending to it.
If you’re generating HTML pages with LiveCode Server, you can use a Web
browser for the client. If you’re generating XML or JSON content, the
client can be any app that can handle those formats. A LiveCode
standalone can handle all of those too, along with image files and just
about anything else you can throw at it.
You can even modify stack files with LiveCode Server and send the
modified stack to the client, but in that case as noted earlier your
client would need to be made in LiveCode since only LiveCode understands
the LiveCode stack file format.
And all of this handles only getting data from the server to the client.
If you want to modify data within a stack on the client side and save
that data back to the server, that’s another set of considerations and
this post has already gotten far too long.
If a LiveCode client is of interest and you could use help in evaluating
options for saving data back to the server, many of us here do this
daily and would be happy to help.
—
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
______________________________
Ambassador@FourthWorld.com http://www.FourthWorld.com
Be First to Comment