ok I really like the layering of deserialization-unaware connection => handler => and deserialization-generic Event.
this might be a non-issue if (once?) the built-in handler becomes also generic over T, so custom record deserialization wouldn't require re-implementing handler. but.
the arc<mutex<cursor>> feels a little leaky and implicit in that first connection => handler interface. a custom handler needs to update the cursor, but nothing forces it to do so. the easy path (ignoring it) leads to eventually full-jetstream-replay on any client reconnect.
mostly just curious if you have thoughts about it! maybe the connection interface can grow a hook for a handler to implement. or maybe it's fine and can just be documented -- maybe the connection layer can consider a cursor "invalidated" if it was given a cursor, has successfully received events, and hasn't seen the cursor change. maybe...
ok I really like the layering of deserialization-unaware connection => handler => and deserialization-generic Event.
this might be a non-issue if (once?) the built-in handler becomes also generic over T, so custom record deserialization wouldn't require re-implementing handler. but.
the
arc<mutex<cursor>>feels a little leaky and implicit in that first connection => handler interface. a custom handler needs to update the cursor, but nothing forces it to do so. the easy path (ignoring it) leads to eventually full-jetstream-replay on any client reconnect.mostly just curious if you have thoughts about it! maybe the connection interface can grow a hook for a handler to implement. or maybe it's fine and can just be documented -- maybe the connection layer can consider a cursor "invalidated" if it was given a cursor, has successfully received events, and hasn't seen the cursor change. maybe...