Awesome, thanks for the explanation Ulf!  I'm going to give it a shot.<div><br></div><div>--Andrew<br><br><div class="gmail_quote">On Sat, May 19, 2012 at 2:40 AM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><br><div><div>On 19 May 2012, at 01:38, Andrew Berman wrote:</div><br>

<blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing: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><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>
<div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a></div></div><div><br></div><br>
</div>
<br></div></blockquote></div><br></div>