Hi Denis,

in addition to what Joh-Tob said, let me correct some issues about
'app'.

> b) I understand that calling the (app) function allows multiple users to 
> access
> an application at the same time, which makes web apps and collaborative 
> software
> possible

What (app) really does is establishing a "session".

When a client (browser) connects to the server, the server forks a child
process which sends a response to the request. This is typically a GET
request, and the child sends a HTML page to the client. At the same
time, the server parent process continues to listen for further
requests.

Now, when (app) is NOT called in the child while it generates its
response (i.e. it sends a static page), then the child process
terminates.

If, however, (app) is called, the child does not terminate. It allocates
a new port to listen for further requests from that client, allows
login, keeps the session's state, and so on.

So multi-user access to the application is also possible without (app),
but each request will be answered in a fire-and-forget style.


> a process listening on different port is created for each user isn't it?

right, this is what is happening.


> So how do you avoid conflict when running independent applications?

To have more than one application running on a single machine, you start
several server parent processes. Each of them will be independently
listening on its own port. We use 'httpGate' as a port proxy, so that
from the browser's view the port is always 80 (HTTP) or 443 (HTTPS), but
is relayed on the server to the right port (and thus server process).


> In case of single user desktop apps, not calling (app) and reserving a port
> seems sufficient. But in case of several users?

So, as you see, (app) has nothing to do with single- or multi-user.
Also, a single application will need (app) to allow sessions, and this
in turn has nothing to do with how many users access this application.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to