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 <[email protected]> > 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 > ____________________________________________________________________ > [email protected] http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
