Clojurians Log v2

@mihaelkonjevic https://github.com/cark/cark.keechma.behavior-tree

I have a question, those behavior trees can send events, and the controller has an API to execute these. they're passed the controller itself, the app-db-atom and the event arg

The question is, should they, in your opinion, receive the app-db-atom or just the app-db, leaving them to other devices if they want to update it

or maybe let them return a naked app-db ... I opted for the app-db-atom thinking that's the most versatile

Also i disagree with the direction of your <cmd arrows ! you're viewing this from the perspective of the guy that made the controller, rather than the user, and it's the opposite direction compared to core.Async !

too late now to do anything about it though =)

I use app-db-atom for lower level interfaces, because it makes it easier to build abstractions on top of it, and app-db for apis that have deref and timing guarantees. As for the arrows on cmd and sub, they are from the perspective of a component (incoming or outgoing). I think they were inspired by some re-frame wiki page with the ideas for helper apis, so I picked it up from there :)

The lib looks really interesting, can't wait to do a deep dive

hah well i was only nitpicking with those arrows =)

There is no timing garanties in this case, those events are there to start websockets or do any number of other side effecting stuff, so i guess i'll keep it as is

thanks

there is an overlap with pipelines, my stuff is more verbose, bigger machinery, probably a bit slower, but is more versatile and totally testable

This looks very powerful, and I'll have to dig in more, but I did have cases where something like this would be a perfect fit

let me know if you find bugs ! now back to regular app dev =)