On 17 May 2002, Andrew Kuchling said:
> I was also thinking of multiple applications from different authors.
> For example, someone writes a Slashdot clone using Quixote, and
> someone else writes an IMAP mail browser, and you want to run both of
> these on your server.  Both applications require session state, and
> you can't let them step on each other's state variables.

But that won't work unless the sysadmin writes a custom driver script,
and sysadmins ain't gonna do that.

Keep in mind that there are already two Quixote apps running on
www.mems-exchange.org: the virtual fab and SPLAT!.  Each has a separate
driver script, a separate persistence mechanism, a separate session
class, and a separate session cookie.  (And if I ever get around to
hacking on SPLAT! again, they might have separate authentication
mechanisms too!)

That's another good reason to get rid of "application state" -- the
notion of a "Quixote application" has developed since then, and the
virtual fab is our main application -- *not* the run builder or run
tracker or file upload area; those are just parts of the great big
complex virtual fab.  IOW, "application state" is a misnomer.

OK, here's what I'm thinking now: I am definitely *not* going to
document ApplicationState.  Jon has already figured it out from reading
the docstrings.  I am still leaning towards removing it, but if I do,
that will trigger Quixote 0.5 -- removing functionality in a point
release, however overdesigned and unnecessary, is just evil.  If anyone
howls mightily enough, I'll leave it in.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org