It would probably add some, but probably not too bad.
> The other idea I had was to expire events in a given discussion
> every time a new event is generated for that discussion. This
> would distribute the load of event expiration. This has the
> potential of not removing events for discussions that have been
> idle longer than the expiration age of events.
"Events" in this case includes the notifications for people entering
and leaving the discussion (when they are idled-to-death, or if
they /bye), right? If so, then the above wouldn't be much of an
exposure. I'd say start with this, and maybe later see if we also
have to add a check during checkpoint time.
> In any case, the expiration age will be stored in a property of
> the review manager that will be settable by the lily administrators.
> Users will also have the option of reducing the expiration age
> for any discussion that they moderate.
> As a final note, I would like to do a survey of the age of events
> in discussion review buffers before this is implemented.
Some discussions get enough activity that they won't be killed,
but it takes a long time to get 500 events worth. I know that when
last semester started (September), the ACM discussion had events
in it from the end of the Spring semester. I do a '/review 4-its
clear' every once-in-awhile too, because the 500-event buffer might
go back for well over a month.
Doing a survey of the current discussions would be useful. I think
Christian looked into that at one point, but maybe it was bp looking
into it on his own server.
One advantage of doing this is that we could let discussions remain
for longer stretches of idle time, as long as we had older events
expire from the discussion. This would be good for some of the
standard-ish discussions, such as 'rcs' or 'security'.
Actually, I've had some other ideas which were meant to address
those kinds of discussions, but I'll leave those for some other
day. They aren't as important to me as these changes are, or the
changes to help with clients wanting to do fancier processing (such
as cloverleaf-style clients).
--- Garance Alistair Drosehn = firstname.lastname@example.org ITS Systems Programmer (handles NeXT-type mail) Rensselaer Polytechnic Institute; Troy NY USA