> Under mod_perl, packages/scripts remain in memory across requests, for the
> duration of the Apache child.
> The second issue is that, due to the stateless nature of HTTP, requests are
> dispatched to Apache/mod_perl children at random. You can't store
> information about a particular user or user's session in a perl variable and
> expect that user's next request to be sent to the same Apache/mod_perl
> process. This is why there are so many modules and techniques for storing
> user session/state information using various files and databases.
Indeed, thanks. I let a javascript function receive the result from the Ajax
perl function, rather than the <div> element directly. Then also in a <script>
block I put the declarations of those few state variables I wanted. I guess
that way they will be in the memory on the client browser side, which is what I
intended. Then the javascript can do what needs to be done to incorporate the
server response into the local page state and update the div(s) accordingly.
This leaves me with only two problems, a lack of javascript knowledge and the
cumbersome way to put javascript into strings in the handler module, for
example I ended up escaping some quotes as \\\", others as \", and then the
perl quotes as ".
