I have seen several tutorials on this subject. They say a "home stack" is "created" on startup (presumably the startup of the CGI, which must happen an awful lot on a moderately employed server) and that you can then use "global scripts". This sounds pretty much like gobbledeegook to me. I understand basically the message path on an application level, but I don't see how to connect a stack with a web page, unless you're using includes (or requires), which kind of makes the stack like a "library" in php. I've seen the "go to" stack command on the server, but I don't know really what that does (it obviously creates a reference, but without an include, I don't know how, unless you're creating a web app like asp.net or you're adding packages like node).

I'm going to assume there's no "message path" per se on a web application, and there are no "cards" as such, so if I had a web (.lc) page of any kind, how would I make use of a stack? Where is the stack, what is it called, do I use an "include" to reference it, and can someone point me to a link that explains the part about the "default" stack being "created on startup", because it strikes me that this would be very difficult to use for anything.

I've used the include and require on LC server, so continuing on in that vein would not be a big problem, since it's just like php, which I'm middling familiar with. The various sources of (sparse) documentation, however, suggest there is a more "stack-centric" way of doing it.

So does that mean I can ignore the "stack" concept (as I would with PHP) when using the server?
And does that mean anything external (other pages) get referenced by includes and requires?
And does the statement "Home stacks are created at startup" (which I've read) mean anything?

4th paragraph:
"At start up, a 'Home' stack is created which serves as the container for the global script. This stack sits at the root of the message path and works in much the same way as the IDE home stack - it sits after all mainstacks in the message path, but before library stacks and backscripts. Global script execution begins with the main script file. "

"A 'Home' stack is created at start up, which serves as the container for the global script on a LiveCode Server application. This stack sits at the root of the message path and works in the same way as the IDE home stack, which sits after all mainstacks in the message path, but before library stacks and backscripts."

They're talking about the 'global script' and 'message path'. Some places suggest there's a 'message path' in the server environment (can't see how, unless it's the file path common to other web environments). A 'global script' is cited in several places. Is this a script containing globals, or common functions? The second article mentions the includes. If a file's included, I don't see the relevance of the 'message path' or 'global script'.

I'd like a link to that article myself. I seem to remember coming across a bit about creating stacks that ran in the browser on BYU, but I was never able to find it again.

BYU mentions "embedding a browser in a stack" which is a reference to the LC Browser control.

In the LC "Cloud and Database" Lesson series, it demonstrates opening a stack in a client app from a web server. How this would be functionally superior to a browser page I don't know, but it seems it was intended as a demonstration of a "thin client" that didn't need rewriting or individual updating, as it drew all its logic from the server. It's a neat proof of concept but the server code to all this was kind of a black box (from what I've viewed thus far).

BYU mentions "embedding a browser in a stack" which is a reference to the LC Browser control.

That may be, *now*, but it is not what I was referring to.

In the LC "Cloud and Database" Lesson series, it demonstrates opening a stack in a client app from a web server. How this would be functionally superior to a browser page I don't know, but it seems it was intended as a demonstration of a "thin client" that didn't need rewriting or individual updating, as it drew all its logic from the server.

This is actually closer to what I was thinking of, except not as a thin client, but literally in a browser. I'll have to see if I can find it again, and then whether or not my mind is playing tricks with me.

BYU mentions "embedding a browser in a stack" which is a reference to the LC Browser control.

That may be, *now*, but it is not what I was referring to.

In the LC "Cloud and Database" Lesson series, it demonstrates opening a stack in a client app from a web server. How this would be functionally superior to a browser page I don't know, but it seems it was intended as a demonstration of a "thin client" that didn't need rewriting or individual updating, as it drew all its logic from the server.

This is actually closer to what I was thinking of, except not as a thin client, but literally in a browser. I'll have to see if I can find it again, and then whether or not my mind is playing tricks with me.

Well, when you think about it, an .lc web page (like a php web page more or less) is a "stack" composed of one or more files, maybe a main display page, a header and maybe a library page. When you hit the server to ask for that page, you are getting a "stack" back in return (literally the results of a stack). The actual code is executed on the server. That is really all a browser can do, unless it's running java or an application linked to the server. I guess that's the difference with the "thin" client they demonstrated in the Cloud and Database lessons. The client could run LC code by itself.

I don't know much about it, but LC has this HTML5 app schema, which seems to be a self-contained app of some kind using some LC to javascript links or conversions (I'm sure I'm butchering this because I haven't read enough). Maybe that's what you read.

I myself browse BYU quite a bit (largely because their website is way faster than Livecode's). I'll keep an eye out for these references. I'm on the lookout for anything that talks about the LC server coherently and more or less sequentially.

4th paragraph:
"At start up, a 'Home' stack is created which serves as the container for the global script. This stack sits at the root of the message path and works in much the same way as the IDE home stack - it sits after all mainstacks in the message path, but before library stacks and backscripts. Global script execution begins with the main script file. "

Thanks. That makes sense, given that LC scripts are properties of objects, and a "home" stack is as good a fit as any for an arbitrary script container object.

It's an interesting detail, but in 20 years with this engine (much of that on servers) I've never bothered to notice that the script is loaded into a dynamically-instantiated "home" stack, and have never seen it referenced that way.

I suppose it may be useful information in some rare circumstance, but offhand I can't imagine what such a circumstance would be.

They're talking about the 'global script' and 'message path'. Some places suggest there's a 'message path' in the server environment (can't see how, unless it's the file path common to other web environments).

LiveCode always has a message path, which defines how messages travel among the various scripts that may be in play at any given time.

In server environments it's common to use libraries, and if you're generating graphics the rest of the message path (card -> stack) may come into play as well.

A 'global script' is cited in several places. Is this a script containing globals, or common functions? The second article mentions the includes. If a file's included, I don't see the relevance of the 'message path' or 'global script'.

Per the article, the script used to initiate the session is the "global script", the one for which the "home" stack is instantiated.

Richard Gaskin
Community volunteer LiveCode Community LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

In the LC "Cloud and Database" Lesson series, it demonstrates opening a stack in a client app from a web server. How this would be functionally superior to a browser page I don't know, but it seems it was intended as a demonstration of a "thin client" that didn't need rewriting or individual updating, as it drew all its logic from the server. It's a neat proof of concept but the server code to all this was kind of a black box (from what I've viewed thus far).

If all that's happening is downloading a stack file, no code is needed on the server. In that case, it's pretty much the same as reading it from disk, except the disk happens to be on another computer.

The benefit of native apps vs web apps is pretty much the same on the desktop as it is on mobile: offline options, complete cache control, faster and smoother UI rendering, better integration with the host OS, more control over the UI, etc.

Richard Gaskin
Community volunteer LiveCode Community LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

I don't know much about it, but LC has this HTML5 app schema, which seems to be a self-contained app of some kind using some LC to javascript links or conversions (I'm sure I'm butchering this because I haven't read enough). Maybe that's what you read.

It is unfortunate that I have not been able to find the reference to what I read, it appears to have been removed at some point. Several of the pages I bookmarked from BYU in fact no longer respond.

I remember remarking about it here on the forum at the time I read about it, and I am pretty sure it was not the html 5 stuff. What I seem to remember the general answer being was that it was a feature no longer used/supported, which leads me to think it must have been something like revlets, or along those lines.

That is really all a browser can do, unless it's running java or an application linked to the server.

Yes, it was very much like a java applet embedded in the browser page, from what i remember of working in early VS (95-97), where you could build a little java applet and run it directly in the browser, kinda like flash games and the like. It wasn't an html form or anything like that, and it is similar to the way the html 5 application structure is going forward, although it seemed faster loading and more complete.

I myself browse BYU quite a bit (largely because their website is way faster than Livecode's).

I spent several months poking around it myself, it is certainly a great reference