Joh-Tob, thanks, of course you are right, it is the job of the OS to prevent 
such conflicts, how could I have forgotten that!!! And thanks for pointing the 
c source file.

Alex, thanks for the explanations, as I had not understood that picolisp 
behaved like a web server without the calling app. (app) is an elegant solution 
to the stateless browser problem.


> From: a...@software-lab.de
> To: picolisp@software-lab.de
> Subject: Re: questions about the gui
> Date: Sat, 21 Nov 2015 12:55:23 +0100
> 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
                                          PԔ � &j)m����X�����zV�u�.n7�

Reply via email to