[not quite OT] Serving a standalone

Paul Dupuis paul at researchware.com
Sun Feb 8 10:01:42 EST 2015


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.




More information about the use-livecode mailing list