so i don't need to update this every time i do a release :-) and i like
this older image/badge a lot more than the newer style one that clojars
has now ...
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?
trying to reduce the number of times i de-reference session-atom, as
well as reduce the number of bits of data i obtain from it before/after
a call to swap! within the same function. was able to cut out a few
here which i think should be pretty good. :-)
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).
i think this weird assoc was a leftover artifact from the old
event-fn stuff that i removed already? either way, performing an assoc
here is entirely useless so lets get rid of it
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.
if a number is not provided, then every time the sweeper thread body
executes, it will try to sweep the entire session, even if nothing
has read/written the session store in the mean time. this is also now
the default behaviour. the thinking here is that this allows for the
best real-time-feeling behaviour with regards to session expiry,
especially for low-traffic / low-activity web apps. applications
that care more about performance, can easily set a threshold here and
get the old behaviour back.
apparently this is a little bit faster than calling now once and then
passing it around as an argument. i have to admit i was not expecting
it to be a small but noticeable difference. i guess the JVM is really
able to optimize calls to System.currentTimeMillis() well?
of note is that there is now some possibility for very slight
discrepancies with the timestamps being set in a larger session map
across sweep-session calls (for example) because we are repeatedly
calling the 'now' function.
this is _probably_ not a big deal though.
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