i'm not totally convinced that it is that useful? i feel like just
making the sweeper thread run less frequently would solve most of the
same problems that the threshold was (possibly?) intended to solve?
mainly because calling on-expiry for delete-session doesn't feel
appropriate if we're talking about an "expiration listener." calling
it a "removal listener" feels much better (especially now that we also
have a third argument containing the reason for removal, allowing
people to tell which is which).
this is a change for functionality that will almost never, ever be used
in practice. but i just didn't like the idea of the 'aging-memory-store'
function creating a thread that you then had no control over whatsoever
after it returns ... maybe someone, somewhere will benefit from this.
the events function stuff always seemed very overkill to me. i cannot
think of any other criteria i've ever wanted for session expiry other
than "expire based on some period of idle time elapsing" and an event
function being used to provide this seems a bit too much to me.
thusly, this has all been replaced with a simple ttl value (specified
in seconds) as a non-optional argument to aging-memory-store.
also change the aging-memory-store opts parameter, it must now be an
explicit map if provided
Gered