Stacks and livecode server?

EED-wp Email prothero at earthednet.org
Tue Apr 21 09:13:43 EDT 2015


Peter
I think it would be very hard to justify the effort required for a livecode book, given all of the changes in livecode on the horizon. Keeping it up to date would be a huge effort, too. 
Best
Bill

William Prothero
http://ed.earthednet.org

> On Apr 20, 2015, at 10:08 PM, Peter Bogdanoff <bogdanoff at me.com> wrote:
> 
> Richard,
> 
> This is a great explanation!
> 
> You didn't go on long enough!
> 
> I would LOVE a good reference book/ebook/application on using LC,  LC server, and web services in general.
> 
> I would easily pay $100 for such a thing if it really got me going in this field. I know LC desktop pretty well but have all sorts of needs for this kind of thing, but what available is (for me) a daunting conglomeration of resources.
> 
> Peter Bogdanoff
> 
>> On Apr 20, 2015, at 10:59 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




More information about the use-livecode mailing list