Fork me on GitHub
#clara
<
2018-04-10
>
mikerod18:04:17

@whilo I’m not completely up-to-speed on all of the various references you posted here. I can at least (for now) add a bit of light on the “durability” side of things. Clara does currently have some (fairly raw) support for session and working memory durability. More on that can be read about first @ http://www.clara-rules.org/docs/durability/

mikerod18:04:40

Much of the working memory side of the durability implementation is up to your particular use-case

mikerod18:04:03

Clara does provide a Fressian backed impl of durability for the Clara infrastructure part of the rule sessions themselves

mikerod18:04:28

it offloads all facts in working memory to a separate protocol, that the consumer would implement to effectively serialize their facts.

mikerod18:04:00

Since I’m not familiar with each of the points you mention above though, this may or may not suit the goals you have

mikerod18:04:23

I need to read a bit deeper into some of your links to have anything else to say on the subject I think

mikerod19:04:49

It seems to me that you may be interested in a way to store facts in a way that are out-of-memory, perhaps because the set of facts will grow to potentially too many to fit all in memory at once.

mikerod19:04:48

In that case, the durability alone won’t be enough. I think you’d then have to do a custom implementation of the memory layer of Clara, as you’ve mentioned. In Clara’s early days, Ryan Brush (the creator of Clara) had a demo project that prototyped how Clara’s working memory could be realized over a distribution cluster using Apache Storm

mikerod19:04:20

https://github.com/rbrush/clara-storm This isn’t maintained and very likely doesn’t work now. However, perhaps it is inspiration or at least related to some of your ideas you’ve mentioned above.