LiveCode Forums.

I have been developing a stack that integrates video content and concept mapping to enhance learning in computer-based instruction. Most features work fine, student performance is stored in an SQL database, etc. What I'm considering now is distribution of the stack to students and want to convert this to run on the Internet rather than students each having to maintain their own copy.
I believe 4.0 will address this. My question is- will it support the learning activities (e.g. students construct interactive maps while viewing which they will need to access in later sessions) and how soon this feature will be available (i.e. how difficult will it be to convert the existing materials)? I want to conduct a formal evaluation of the resources during the fall semester and need to know how feasible it would be to incorporate the Internet delivery format.

Rev 4.0 is reported to include a web browser plugin, which AFAIK is expected to be delivered in a beta state in September. So if you need your stacks to run specifically inside of a browser window, the browser plugin may not be ready in time for your fall semester deployment.

But why wait? You can deploy stacks over the Internet right now, just using a standalone instead of a browser.

You can put a stack on a server and have your standalone download it in one line: That'll download and open the stack.

For faster delivery you can compress stacks using Rev's built-in compress command, and download them like this:
You can also integrate a chat feature if you like, using the Chat Example included with Rev as a starting point.

And you can use FTP to have student post materials if you like, again with most operations being one-liners.

The possibilities are endless.

Lots of examples from folks who've been deploying stacks over the web:

Info on Reactor Lab:
http://www.revjournal.com/features/reactorlab.html

Dynamic Digital Maps:
http://ddm.geo.umass.edu/

RevNet:
in Rev, see Development->Plugins->GoRevNet

In RevNet's Stacks section is a handy utility called "4w gZipper" which lets you drop files onto it and it'll make a compressed copy for you.

You're welcome to use any of the code in the RevNet stack if it's helpful for you.

Thanks for the input.
One advantage I see is that they will always be using the latest version of the stack so updating will be easier.
As part of this activity students will be using a card with a video player and a series of objects to control the video playback. I assume that will work. I'll be recording their choices, etc, but I assume it will all be easily sent to an SQL database for later access as in regular stack access.

However, students will also be constructing a card with a series of control objects that they will create- will that work with Internet access and a single file access, or will I need to create a separate stack for each student? will that stack be savable over the Internet so that the controls will be there the next time the student downloads it? The 'Dynamic Digital Map' reference may answer that- I'll look at it more closely.

With playing QT over the web, Rev can use URLs as the filename for a player and it most cases it works well, but be sure to optimize the video for web playback for smoothest delivery.

As for saving the stack, there are three ways I can think of offhand to do it and these would be the same options you'd have whether using a browser plugin or your standalone (or maybe much easier in a standalone, since I'm not sure how you could use FTP to transfer a stack from the plugin, given that the stack can't be saved locally with that):

- FTP: save the stack locally, and use Rev's lbURL to transfer it to your server with something like: - Post the stack to CGI or MySQL: MySQL DBs can have blob fields, so conceivably you could use the POST command to transfer the stack to the DB for storage there, or with a CGI to store in a file. Note that POST has some limits on data size which may vary from server to server, so this would be most useful for relatively small stacks.

- Stack data: Depending on the scope of changes allowable in your stacks, it may be simpler to identify changes in a stack and send the data that describes those changes via FTP, CGI, or PHP/iRev/MySQL. With a chess board, for example, this would be simple to do since you're only dealing with positions of objects. With more complex stacks this may not be practical.

One nice thing about using a standalone for this is that you can also provide an offline mode, so students can work on their stack even when they're not connected if you like, posting it back the next time they connect. I do a lot of work on trains and planes so offline mode is an important consideration for many systems I use.