RevServer deployment on OSX Server
keith.clarke at clarkeandclarke.co.uk
Fri Feb 18 14:32:19 EST 2011
Thanks for persevering with me Jaque (et al). I think I get the subtlety now.
RevServer will not be a web server that interprets deployed stacks' UI elements as web pages. Stacks deployed to revServer are purely a convenient container for server-side scripts - to avoid the need to save the scripts out to text files. Any browser UI elements would be contained within a separate revlet stack that is deployed to the server as an application - to be downloaded into the LiveCode plug-in within the browser.
So, development of client and server functionality is undertaken separately and as revServer ≈ PHP, the LAMP server stack becomes LAML - or, if arrays are sufficient for persistence, LAL.
I get it but given my requirements, that begs another question - and another thread...
On 18 Feb 2011, at 19:02, J. Landman Gay wrote:
> On 2/18/11 3:10 AM, Keith Clarke wrote:
>> Thanks for the clarification Jaque.
>> So, my expectations for the shipping version weren't too far off - as
>> it would allow development using stacks (as with the desktop apps)
>> and upon deployment to the server, a standard browser would be able
>> to interact with the UI-specific, stack pages on the server, without
>> the need for the rev web plugin.
> No, I'm afraid that's impossible unless you use revlets. Browsers don't know anything about how to display stacks or their components. They wouldn't know what to do with a stack, just as they don't know what to do with a Flash file. All a browser knows is that it should direct those files to a specified plugin. There is no native support for Flash files in a browser, just as there is no native support for LiveCode stacks. I think you are confusing client-side and server-side scripting.
> Support of stacks in irev just means that you will be able to insert the script of a stack (and possibly other objects) into the message hierarchy so you can use its handlers in your iRev commands. I didn't know it before, but Bjoernke mentioned it might also allow you to reference and send images stored in the stack for use in the browser (browsers do know how to deal with images.) So that would allow you to store all your images in a single stack instead of offloading them separately to an images folder on the server.
> The server product is much like PHP; it allows you to create dynamic web content by using scripts that create HTML on the fly. It does nothing at all with the browser display; it can't. The server can only send HTML back to the browser, and it is up to the browser to figure out what to do with that. If the browser doesn't recognize something, it looks for a plugin that can display it; if there is no plugin, you get an error. If the content is HTML or something else the browser does understand, it renders it and you see a web page.
> The server product already does what it's supposed to, and it works well. We are missing the ability to insert a stack script as a library, but that is easily worked around by copying the script to a text file and including it that way. We are also required at present to load all images onto the server instead of storing them in a stack file, but that is the standard for web development anyway.
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode