<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 19 May 2012, at 01:38, Andrew Berman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ok, cool, thanks Garrett. <div><br></div><div>Do you have any experience using gproc for pub/sub?</div></span></blockquote><br></div><div>Gproc does do pub/sub fairly well, but if I may, the main purpose of </div><div>gproc initially was to serve as a form of "property index" for processes.</div><div><br></div><div>It had dawned on me that complex signaling applications tended to</div><div>end up with a lot of code that basically provided different sorts of </div><div>mappings to allow you to locate the right processes. Having so many</div><div>different mappings complicated debugging, and obscured many </div><div>aspects of the architecture.</div><div><br></div><div>When we started using (the predecessor of) gproc in some Ericsson</div><div>projects, there was significant code reduction. The nice thing was that </div><div>the developers picked it up themselves; there wasn't really any central</div><div>decision to go with it.</div><div><br></div><div>One of the things I like about gproc is that it allows you to publish the</div><div>'interaction features' of a process: registered aliases say much about </div><div>what services a process can perform, and properties illustrate its </div><div>dependencies on other processes. The registry can be queried with</div><div>select operations or QLC, or simply with gproc:i() from the shell.</div><div><br></div><div>In short, there are many fine ways of doing pub/sub, but if you use </div><div>gproc consistently for this sort of thing, and similar things, it can help</div><div>clarify runtime aspects of your system, making it more transparent and</div><div>easier to debug.</div><div><br></div><div>This also explains why gproc relies on a central registry (which is a</div><div>challenge in the global case). The registry itself is much of the point.</div><div><br></div><div>Of course, for a distributed pub/sub, you don't really need to turn on </div><div>the distributed parts of gproc. Running a local gproc instance on each</div><div>node, you can publish like so:</div><div><br></div><div>publish(Event, Data) -></div><div> rpc:eval_everywhere(</div><div> gproc, send,</div><div> [{p, l, {?MODULE, Event}}, {?MODULE, Event, Data}]).</div><div><br></div><div>BR,</div><div>Ulf W</div><br><div apple-content-edited="true">
<div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com">http://feuerlabs.com</a></div></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></body></html>