Stacks and livecode server?

[Richard Gaskin]

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.livecode"

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 at FourthWorld.com                http://www.FourthWorld.com