<div dir="ltr">I'd been waiting for maps to settle down a bit before I looked at them too hard, but that's not a bad idea. Â <div><br></div><div>It appears the dialyzer support in eep 43 is already here in 17, which eases my concerns about contracts and documentability. Â If only there were a way to limit the keys to a defined list. Â Thanks for the idea, Dmitry!<br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 3, 2014 at 11:07 AM, Dmitry Kolesnikov <span dir="ltr"><<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I am afraid that massive amount of record definition will complicate the system.<br>
Have you considered the use of map or key/val lists as unified format.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Dmitry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 03 Jul 2014, at 20:18, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
<br>
> Consider a system that receives application messages in an extensibly large number of formats (e.g. json, xml, yaml, pictograms, esperanto). Â This system wishes to translate the messages into a unified data format, do various centralized bookkeeping tasks, and then pass those normalized messages off to workers for further processing. Â The system further distrusts the application messages (and the format conversion libraries) and so wishes to spawn a worker for each message and let it crash if nonsense or tomfoolery is involved.<br>


><br>
> A picture:<br>
><br>
> Queue of Incoming Messages -> [Pool of Specialized Translators] -> [Processing Manager] -> [Pool of Workers]<br>
><br>
> The "natural" approach from a C / OO background is to define a layout for the unified format, perhaps as an object or struct, and share that across the specialized translators, the processing manager, and the worker processes. Â And indeed that solves the problem fairly neatly here as well, except you can't walk the streets of Los Angeles without tripping over a hobo brought to desperate circumstances who regales you with his woeful cautionary tale of attempting to perform a live upgrade with a record definition shared across multiple modules in an hrl file.<br>


><br>
> After pondering it, it seems like you can choose at most two of { live upgrades, separation into multiple processes, simple and sensible records }.<br>
><br>
> Needing to choose live upgrades and separation into multiple processes, one then starts thinking of bloodcurdling ways to handle the shared record issue, including:<br>
><br>
> 1. Â Treat record formats as immutable and just keep adding them ('mystate1', 'mystate2', ... 'mystate11'...) along with all of the accompanied handling.<br>
> 2. Â Keep a version field in every record format and start them out being as big as you might ever want them to get.<br>
> 3. Â Clone the OTP source repository and hack in record upgrade messages.<br>
><br>
> I'd be interested in hearing if anyone has any better ideas, or how others have handled this scenario in real world conditions.<br>
><br>
> F.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br></div>