Batching notifications for multiple domains

[laforge49]

How do we move server notifications to a web client?

1. In the "good old days" the client would poll the server for anything the server wanted to send. Polling can be expensive, so the last thing we wanted was to have multiple polling loops--one was bad enough!
2. Then we got the long poll. Basically the server would not respond to a poll request from the client until either a timeout occurred or the server had something to send. On receipt of a response, the client would then immediately poll again. So at any time the server had a pending request from a client that it could respond to when it had something to send.
3. And then we got websockets. So a server could send anything to a client at any time.

Hoplon/castra is like the good old days all over again, except that there may be multiple polling loops as there may be multiple domains. Ouch! Lets develop an API for castra (or that can sit on top of websockets) that passes server notifications to a hoplon client's input cells. Later we can embellish the implementation of the API to support alternative transports.

First, we can register input cells as receiving a type of notification, where each type of notification is identified by a keyword. Of course, we might be able to get fancy and have the mapping handled without the need for registration.

Second, the notifications. These would be a map with an id and a type. The value of the id is a consecutively increasing number specific to each client; the id being used to determine which haplon input cell to update.

Third, we would also have an ack-number. When a server gets an ack-number, it will no longer send any notification with an id less than or equal to that ack-number. Poll requests sent to a server always contain an ack-number and are requests for all notifications with an id greater than the ack-number. On receipt of a poll request, the server drops all notifications that have been acknowledged and sends in a vector all the unacknowledged notifications.

Now when a server has a notification for a client, it assigns it the next notification id for that client and puts it in a sorted map with all the other pending notifications, keyed by that id, where each client has its own sorted map.

The API is pretty simple. A means of mapping notification types to cells on the client and a means of adding notifications to the pending notifications map for a client. We will also likely need a way to control the poll loop as well.

[laforge49]

OK, notifications have an id and a type. But they also need a value--which is what gets put in the client cell.

[laforge49]

Initial draft will be here: https://github.com/laforge49/simple-notifications

[laforge49]

Draft of server-side is working.

[laforge49]

Initial draft is working.

[laforge49]

Oh, still a bit to do on the client side.

[laforge49]

Clients now sort and filter incoming notifications. Client side is (again!) finished.

[laforge49]

I went through the code and changed the names to be more descriptive.

[laforge49]

After discussion with Micha, I'll be breaking out the notification logic into separate source files.

[laforge49]

The code is looking much better now, thanks to Micha. The library code is now in separate source files. And doc strings have been added.

Next step is to put this in a hoplon project.

[laforge49]

OK, Micha, I've done what I can in the new hoplon/notify project. So it is over to you again.

[laforge49]

Thanks Micha! I'll work on testing this now.