persistant web state

[Harry George]

"Max Khesin" <max at cNOvSisiPonAtecMh.com> writes:

> I thought of that, but it is not necessarily efficient to pickle/unpicke.
> Additionaly this scheme assumes that the "data" can be frozen at a certain
> point in time. This is certainly not true for database data and probably for
> most other.
> 

I've used the CGI-cPickle approach.  It works pretty well if the app
itself is complex/time-consuming compared to the cost of
reading/writing the file (true in our case).

The "can't be frozen" problem is because the database typically
doesn't have ALL the state data.  In the pickle approach, you make an
object to explicitly handle all state (including temps, partial
computations, etc.).  Think of it the way you would do a state saver
for a thread. That means each person/client needs his own pickled
state -- which means you are using SSL to get unique ids.

So when the CGI wakes up, it checks the SSL data to get the user's id,
uses that to find the right pickle, and loads the data object.  Then
it looks at the recovered data plus any incoming data fields to
determine the next actions.  When done with a transaction, pickle out
the data object again.

> --
> ========================================
> Max Khesin, software developer -
> max at cNvOiSsPiAoMntech.com
> [check out our image compression software at www.cvisiontech.com, JBIG2-PDF
> compression @
> www.cvisiontech.com/cvistapdf.html]
> 
> 
> "Skip Montanaro" <skip at pobox.com> wrote in message
> news:mailman.1053447822.27386.python-list at python.org...
> >
> >     >> Why not have a long-running process manage a shared memory segment
> >     >> using mmap?  Your CGI processes could then attach to that segment.
> >
> >     Jay> How would that work with Python objects?  I thought mmap was only
> >     Jay> for file objects?
> >
> > Couldn't you pickle the data you write to shared memory?
> >
> > Skip
> >
> 
> 

-- 
harry.g.george at boeing.com
6-6M31 Knowledge Management
Phone: (425) 294-8757