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