From: rasmus@madhaus.utcs.utoronto.ca
Date: Thu, 30 May 1996 09:52:09 -0400 (EDT)
Subject: An idea for state saving
To: new-httpd@hyperreal.com
Message-ID: <ML-2.3.833464329.7419.rasmus@rathaus>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

For things like mod_php or mod_fastperl, and perhaps even FastCGI
persistant processes, it might be possible to have the server maintain
state across requests.

For example, with mod_php, one might write a script which does an mSQL
query that returns 100 records.  It is currently very difficult to
display these 100 records 10 records at a time without jumping through
hoops or re-sending the SQL query.

With appropriate tuning of the keep-alive time-out it might be possible 
to maintain the actual records in memory between requests.  If users were 
to hit the [Next 10 Results] button before the keep-alive timeout expired 
it should be possible to maintain the records.  

I suppose one could get even fancier and use mod_cookies and some sort
of request hand off mechanism to try to match a user with their last
accessed http daemon, but that would get pretty ugly.

I am not sure how mod_fastperl manages its memory, but mod_php uses
Apache sub-pools.  These sub-pools are automatically cleared by Apache
at the end of each request.  Being able to indicate that a sub-pool's
life should span entire keep-alive sessions would be a valuable feature.
A request record flag would probably need to be set to indicate that
a persistant memory pool is active so the module knows that it is there.

In the case of a multi-page SQL query, the script would be written to
check if the query results were already in memory.  If they are, one
would display the next 10, and if the results have expired from memory
the query would be resent.

-Rasmus