<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><font color="#000000" class="">That’s great, although including the extra distribution subsystem would bringing some complexity. But fdb is a nice piece of technology which may worth the effort. With the coming Riak 3.0 release it would be interesting to make a comparison between the two.</font><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Lin<br class=""></span></font><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font><div><br class=""><blockquote type="cite" class=""><div class="">On 7/06/2020, at 12:38 AM, Leonard B <<a href="mailto:leonard.boyce@lucidlayer.com" class="">leonard.boyce@lucidlayer.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Lin,<br class=""><br class=""><blockquote type="cite" class="">I’ve heard about foundationDB implemented an actor model in some layer of it’s stack. I’m curious about how it fits into Erlang system, does it act as only a storage backend of Mnesia, or does it also come with its cluster feature like riak does?<br class=""></blockquote><br class="">They use a library called 'Flow'<br class="">(<a href="https://apple.github.io/foundationdb/flow.html" class="">https://apple.github.io/foundationdb/flow.html</a>) to implement<br class="">something akin to the actor model.<br class=""><br class="">Since fdb handles the clustering/distribution, transactions etc what<br class="">I'm working on is the access layer to the raw key-value store system.<br class="">If foundationDB design terms this would be akin to a 'layer'.<br class=""><br class="">Traditionally, mnesia's weak point has been in the distribution layer<br class="">(dealing with netsplits etc).<br class=""><br class="">By adding the fdb backend the goal is to offload that responsibility<br class="">to fdb, while still enjoying the benefits of the mnesia API.<br class=""><br class="">It's early days and things are not stable, but it is looking promising.<br class=""><br class="">Leonard<br class=""><br class=""><blockquote type="cite" class="">Lin<br class=""><br class=""><blockquote type="cite" class="">On 4/06/2020, at 11:08 PM, Leonard B <<a href="mailto:leonard.boyce@lucidlayer.com" class="">leonard.boyce@lucidlayer.com</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">I've been evaluating FoundationDB for a few weeks on another project<br class="">and it struck me that while it seems promising it was a little odd to<br class="">work with the NIF driver in erlang.<br class=""><br class="">So, in the spirit of community, and building on the great work of the<br class="">Aeternity (mnesia_rocksdb) and CounchDB (couchdb-erlfdb) tems, I<br class="">thought having FoundationDB as an alternative mnesia backend may make<br class="">some sense.<br class=""><br class="">This is an early stage announcement as it's just passed the<br class="">proper-based tests from mnesia_rocksdb.<br class=""><br class="">Feedback and issues are welcome as I'm sure things can be improved.<br class=""><br class="">Leonard<br class=""></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></div></div></body></html>