Craig R. McClanahan typed the following on 07:05 PM 3/27/2001 -0800
>Kief, a while back (when the work on PersistentManager was going on), the
>need for a little refactoring work on Manager vs. StandardManager would be
>useful. Have you thought any more about what we should do here?
Yes, in fact I was just working on this last week, playing around with
different ways of attacking this. Replacing dependencies on StandardManager,
StandardSession with dependencies on the Manager and Session interfaces
is relatively easy, with a few additions to the interfaces required. Another
problem I've been tackling is the architecture of the Manager hierarchy.
The problem is that there is code currently in StandardManager which
is needed by (and currently, duplicated in) PersistentManager, which
isn't good for maintenance.
StandardManager implements the Lifecycle interface and functionality
to expire sessions with a background thread. These are also used
by PersistentManager, with the session management code being
extended to handle swapping out idle sessions and similar tasks.
Currently, StandardManager also has persistence code, which is used
only to handle saving sessions on restarts. This code doesn't use the
Store system.
There are two approaches which seem like they would address this.
One solution is to make StandardManager and PersistentManager
subclasses of a common superclass with the functionality common
to both. Another is to make PersistentManager a subclass of
StandardManager.
The first approach, making a hierarchy, appeals to me because it
makes it easier to experiment with alternative session managers.
DistributedManager would become a sibling to StandardManager
and PersistentManager. This solution requires either moving the
common functionality into the ManagerBase class, or creating
an intermediary abstract class. The second approach allows the
ManagerBase to remain a clean implementation of the Manager
interface, although it extends the hierarchy an extra level.
The second approach doesn't appeal to me, mainly because it
seems likely to get a bit muddled over time.
Either way, another issue I see is that StandardManager, as long
as it supports persistence on restarts, is going to use a fair amount
of the code from PersistentManager. This isn't necessarily a bad
thing, it will keep PersistentManager fairly simple. But I would
prefer to make it easy to develop a fully working Manager which
doesn't include any persistence whatsoever: either StandardManager
could have this (requiring users who want restart persistence to
use PersistentManager), or there could be a separate SimpleManager.
The first of the two solutions: making StandardManager and
PersistentManager siblings rather than one a subclass of the
other, seems likely to offer cleaner support for a StandardManager
without persistence and/or a SimpleManager.
Once the beta is tagged (this weekend?) I can start committing
some work on this.
Kief
