<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 1, 2015 at 4:33 AM, Khitai Pang <span dir="ltr"><<a href="mailto:khitai.pang@outlook.com" target="_blank">khitai.pang@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
How to store the data on disk? Mnesia?  How to organize the data? Does erlang has some OTP-fu to handle tree data?  Does erlang has a way to do mutex?  How do erlang server and clients talk to do data syncing?  Can the syncing be done by communicating with raw Erlang terms?<br>
<br></blockquote><div><br></div><div>There are many ways to store on-disk (although I like Kevin's LDAP idea best). Mnesia is neat but might not be what you want if your goal is to sync with clients. There are a number of key-value storage engines that could work, or you could just the entire data structure write to a file occasionally.</div><div><br></div><div>For the data you are modeling, records or maps seems appropriate (although, I'm wondering how a branch of the org tree doesn't have a manager where the branch's children are her direct reports). If it were records, I might do it like so:</div><div><br></div><div>-record(branch, {children=[] :: #employee{} | #branch{}}).</div><div>-record(employee, {name :: string(), title :: string()}). </div><div><br></div><div>From that it's straightforward to do depth-first traversal of the tree:</div><div><br></div><div>traverse(#branch{children=C}, Fun) -></div><div>    lists:foreach(fun(R) -> traverse(R, Fun) end, C);</div><div>traverse(#employee{}=E, Fun) -></div><div>    Fun(E).</div><div> </div><div>"Mutex" is something that doesn't really exist in Erlang because there's no direct concept of shared memory. Instead, I'd send all mutations (and possibly reads) of a shared structure through a single process whose only purpose is to serialize access to the state of the structure. This is a very common pattern. If you can tolerate reads being unserialized ("dirty" or "stale"), put the state in an ets table that has public reads. This works well in high-read, low-update scenarios.</div><div><br></div><div>Serialized Erlang terms are great, but not incredibly interoperable. I'd go with a more commonly used format. For text, XML or JSON, for binary or more compact representations, I'd use msgpack, Protocol Buffers, or ASN.1.</div><div><br></div><div>"Syncing" is a whole other topic that requires a primer on distributed systems that can't fit in this email. I suggest reading <a href="http://book.mixu.net/distsys/">http://book.mixu.net/distsys/</a> when you have the time. Even implementing a simple best-effort delivery is full of deep potholes, not to mention handling concurrent updates.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Sorry to ask so many questions, some may be off-topic in an mailing list for Erlang the programming language.  I really need some guidance before start working on it.  And I want to know in what way erlangers' would tend to implement this.<br>
<br>
<br>
Thanks<br>
Khitai<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>