Graham, I've had a lot of experience doing this for a 300seat oceanography class. I used my own server to store student work. Students downloaded the software in this instance. They were identified by a 7 digit number. I used a combination of files uploaded and downloaded to a local temp folder, and a MySQL database on my server. Students used my app to gather Earth data, edit and annotate images, and write papers, and review each other's papers, etc. it was pretty complex and modern learning management system do much of this now. There was no licensing because I never did develop that work into a commercial product. Bugs were a major issue until I developed an update system that let me post updates that got downloaded to students' computers. But the main point is that all student work was stored on a server so they could access their work from a computer lab or on their personal computer.
Another project, now limping along was a simulation game built in Director and served as a Flash movie in a browser. I set up a licensing system. Users were identified by their email. I give 30 free licenses to any teacher. They can easily get more by changing their email address. Login management is done thru my drupal website and I wrote a php script to let folks login to my app using their drupal password and username. This effort to manage users, licenses, free licenses, purchases on PayPal, became more complicated and took much more of my time than the game it managed. Thank heavens I don't need the income because I'm pretty sure I'm in negative cash flow with it. Now, of course, Director as a development app has become so creaky that I am loath to invest any more time with it. Currently, my first livecode app is being beta tested in several UCSB Earth science courses. I store student work in a folder, named with their username, on the desktop. I warn them that their files are temporary so they can copy them to a thumb drive or upload to whatever server might be provided. When a new student logs in, the folders of other students are deleted, to discourage cheating. The actual lesson docs are provided separately. I'm planning on adding content, lessons, quizzes, etc, so this is just a test of the most complex part of the app and the "engine" that delivers Earth data in a form that students can easily view and interpret. I am planning on distributing this app for free, at least at first. If I wanted to monetize it, I will put it into the Apple store and charge for it, or give away the basic app and have enhanced versions of the same series. That's it, but please feel free to contact me if you would like to discuss strategies. Integration with modern LMS's is also an issue and I'm not an expert on that, but it's probably important. Best, Bill William Prothero http://es.earthednet.org > On Feb 8, 2015, at 5:52 AM, Graham Samuel <livf...@mac.com> wrote: > > As with so much in this world, technical and otherwise, I am profoundly > ignorant of the following, and I’d be grateful for any explanations, best > practice etc. > > The idea is as follows: > > 1. I write a desktop program (OK, an app) that runs, say, on PC and Mac. Good > LC territory. This program is capable of saving some parameters, files etc on > behalf of the user. Some of these files will be anonymous, in that the user > won’t see them or be able to change their names or file paths - they are just > there to maintain the state of the program between activations - this is a > very widespread notion throughout modern computing. > > 2. Now, some institution - like an enterprise, school etc - buys a “site > license” for the app, which means they’ve paid to have (say) up to 20 > simultaneous users. > > 3. When the purchase is made, someone (probably a technical support person) > loads up the app onto a server belonging to the institution and registers it: > some kind of registration file is kept on the server, controlled by the > initial instance of the app (I’m sure Jacque’s Zygodact would be an excellent > component of this). > > 4. When a user wants to run the app, they sit at their personal computer, > contact the server, and download the app. This is where the fun starts. > > 6. What happens now when that downloaded instance of the app is called upon > to save a file? Is it just saved on the local computer? If so, what if Jack > and Jill both use the program on the same machine at different times? Will > Jill’s files overwrite Jack’s, and if we don’t want this, how can we prevent > it? How much work will the app itself have to do? I think I understand this > one: the app will have to associate each file with a directory created > especially for an individual. This is not hard, especially if Jack and Jill > have separate user spaces - we can insist on this. But maybe these files end > up on the server - does this ever happen? > > 7. While Jill is working, many others start work. Anselma downloads another > instance of the app to her own computer. How does the original copy on the > server know whether this is legit (not greater than the twentieth user in my > example) or not (the 21st user), and indeed how do any of the users know the > app is already registered? More particularly, how much work does the app have > to do to manage this? > > This is really the key question - what do servers generally do to support > multiple instances as described above? Maybe it’s nothing, in which case the > ‘server’ version of the app will need a lot more development work than the > version intended for a single individual; or maybe it’s so much that the app > doesn’t need to know anything about the server once the user has done the > download. > > For me this is a real case, and I just don’t know how to learn more and thus > get started. > > TIA for any discussion and help. > > Graham > > > > _______________________________________________ > 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
