and emit an event when messages are dropped so you can implement your own queuing etc..
Kinda playing off that and whats going on in #20, might be nifty to pass the "identity" to the event and also emit an event (or have a plugin api) when a previously "identified" socket comes back online.
That would basically give us a durable socket implementation with out having to write one lol.
haha yeah as long as we expose that info it should be pretty easy to hook up
Have you thought about this much? I am running into a case for it, but not super sure the best implementation for it... My use case is leveraging HWM so I don't have to add a queue in the middle. I can imagine the event for meeting HWM is straight forward, but the offload process there after is not so straight forward...
// write to db
// offload from db
not much nope, so far our data is very transient but hmm yeah I guess we emit start emitting them when hwm is reached and emit another when things cool down, that what algo would be im not sure. If we were to emit that immediately it could enable thrashing so we might a backoff function for that as well
add HWM support. Closes #19