an additional ZyanComponentHost.ExpiredSessionRemoved event makes sense. But we should keep in mind, that sessions are security critical. So the Session ID of the removed session should not be published to subscribers of this event.
Logon and logoff can be monitored directly by ZyanComponentHost, but removal of expired sessions is encapsulated in the session manager. The session manager must notify its ZyanComponentHost instance, when a expired session is swept away. This must be done
in a asynchronous and decoupled way, because blocking the sweep method - which will happen in case of using ordinary events - may lead to security issues (Someone may delay the removal of further expired sessions).
Another point is backward compatibility to existing ISessionManager implementations. Sweeping of expired sessions is done by the session manager. We can extend the default Zyan ISessionManager implementations with such a new event. But the ISessionManager
interface must not be changed. Otherwise custom ISessionManager implementations of many Zyan users won´t work, after they get the newest Zyan source.
The circumstance that the ExpiredSessionRemoved event may not be fired, if the used ISessionManager implementation doesn´t notify the ZyanComponentHost, must be tolerated.
I suggest to create a seperate interface for notification of removed expired sessions, that session managers can implement. ZyanComponentHost can check, if the specified session manager implements this interface and then inject a callback delegate to receive
the notification. Let´s call that interface INotifyOnRemoveExpiredSession or something like that.
ZyanComponentHost can also provide a property to query if the used session manager supports notification on expired session sweep, or not.