Clojurians Log v2

I think guaranteed delivery is an expectation brought by the big message bus/broker providers and not a truism of all eventing APIs or systems. Agree on no backpressure on cast/pub - I think that is better handled at the system boundaries, e.g. at Bell Labs we had the phones do a backoff algorithm and later a 503 and retry-after equivalent header, but it was the front door (in this case SIP proxy) that knew that, not the event server. FWIW, I've always liked the lingo of SIP, which was initially just subscribe/notify, and they later added a RFC for publish as everyone was sending unsolicited notify's for a NOTIFY that occurs outside of a subscription). In the original spec, you would just send a NOTIFY (e.g. with presence state) and the event server would broadcast that

That looks like the bones of a publish/subscribe event broker? If so it's potentially very useful. The most satisfying architecture I've worked with in embedded C (most of my day job) uses a UML statemachine per subsystem and an event broker connecting them up. Gives you nice boundaries for testing, and discrete chunks of functionality that are easy to reason about in isolation.

I could imagine this being used in some kind of offline sync system which is simpler than CRDTs using a last write wins algorithm. We are already using flow in our systems, so appreciate your work.

It is like pub/sub, though neither pubs, topics nor subs are reified, and 'tuning in' is fully predicative, rather than being enumerated or pattern-matched. signal-ids can be composites and the filter predicates nuanced. And things like one-off signals about e.g. UUIDs are possible.

if you look at the history of that gist you'll see I speculated with pub/sub lingo but rejected it because of the preconceptions it engendered

Looks great -- when we did Session Initiation Protocol (SIP, RFC 3261), we'd have so called in-band signal, ie there was an active subscription, and out of band (ie unsolicited notify), for our phones that would subscribe to the message-waiting-indicator URI (ie when you have a voicemail and want the led lit), and then 3rd party phones that may support something similar but you just have to send them a NOTIFY that there's a new voicemail. I was actually just looking at flow, the various message buses, zeroMQ, and this is timely

The only reservation I have left in using pub/topic lingo is the lack of guaranteed delivery due to the sliding buffers. I don't want to support backpressure on cast/pub