Sessions may be abandoned. Old sessions may become active again. As it stands, the server will track an ever-increasing number of sessions until restarted. And on restarted, clients are given no notice.

Lets start with a :new-session notification. When a request is received, after being assigned a session id as needed, if the session does not in the @unacked-notifications map, then the request is ignored and a :new-session notification is sent to the client. The client must now perform any required session initialization to sync up with the server.

We can also have a priority queue of session ids, keyed by time of last get-notification. When a session has been inactive for too long and/or there are too many sessions, the session is removed from both the priority queue and from the @unacked-notifications map.

We also need a query returning the number of active sessions.

You can have a LOT of active sessions which are really not very active at all. Polling frequency should be high when the client is receiving notices and not so high when notices from the server are infrequent. We can specify a degrading poll timer with 3 numbers:

1. The delay between polls after a notice has been received.
2. The maximum delay between polls when no notices have been received for a while. And
3. The number of milliseconds added to the delay each time a poll is sent.

This simple change will significantly reduce unnecessary traffic on popular web sites.

We need an easy way, i.e. a function, for the server to send a notification to all active sessions.

An active session is one with an entry in the map held by the unacked-notifications atom.

The function would take two arguments, the notification type key and the notification value.

Time is so often overlooked, but in the end it is often needed. Especially if we add durability.

The cleanest way to do this will be to break backward compatibility. But at this point, that is hardly an issue.