[not quite OT] Serving a standalone

Graham Samuel livfoss at mac.com
Sun Feb 8 11:38:27 EST 2015

Paul, that’s a great summary. I shall be studying it carefully.

Thanks so much


> On 8 Feb 2015, at 16:01, Paul Dupuis <paul at researchware.com> wrote:
> On 2/8/2015 8:52 AM, Graham Samuel wrote:
>> 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.
> There is a lot of variation used in serving applications. Let em run
> through some of them:
> 1) The application is downloaded to the user's computer (i.e the
> application's file/folder/whatever is actually copied to local disk
> space on the user's computer like downloading LiveCode from the RunRev
> store). In this case the application is now on the local computer and
> only has access to local diskspace. Unless the "license file" was part
> of the download, the app may need to be re-licensed and any file written
> will be unique to that specific computer.
> 2) The server's volume (disk) containing the application is mounted
> (accessed) from a local computer. Here the app remain on the server's
> disk, but runs on the local computer. Files that are accessed via the
> specialFolderPath function (see Livecode dictionary) in places like the
> temp directory or desktop, etc. will be on the local folder, but file
> accessed from the folder the app is in are on the server and shared
> across users.
> 3) The application is served via an application server. A lot of
> colleges and universities now use application servers such as Citrix or
> Microsoft's application server software. In these instances the
> application is actually run on the server and all it's files are stored
> on the server, but each user gets their own "virtual" instance of the
> application to their files don't conflict. Is system administrators
> allow, application servers can also provide or force access to local
> disk space for user files.
> 4) Also, many places may use desktop management software (such as
> LanDesk or Microsoft's tools) to remotely deploy the application to
> individual users computers through remote control of those computer (or
> a remote "push" of software to those computers. In this case each user
> ends up with their own instance of the software running on their own
> computer.
> There are other ways, but most others are some variants on the
> approaches above.
> _______________________________________________
> 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