Remove dependency on gproc

[esl]

Remove dependency on gproc

[hcs42]

Why does this application need gproc?
Couldn't a simple local name be given to the elarm_summary_sup process?

The reason for using gproc instead of erlang:register is that the former accepts any term, not only atoms. Even though the typical elarm usage will probably be to have one elarm server on one node, it is possible to create new elarm servers dynamically. If we simply used erlang:register for the elarm_summary_sum process of each elarm server, we would have needed to dynamically generate atoms, which is usually not a good idea. The simplest thing to do here was to use gproc.

That said, afterwards we added an elarm_registry module, which stores the pids of all elarm servers on the node. That could be used instead of gproc.

Why not let users choose how they want to register stuff?

This is an internal part of elarm, so I don't see any reason why the users should be able to say "I want library X to be used by elarm to register its components so that they can talk to each other".

But I see that having no dependencies would make elarm easier to be handled, so we will have a look at this question.

[nox]

You don't seem to use erlang:register directly, and supervisor references can use the {via,_,_} values which were specifically introduce to allow OTP behaviours to use gproc.

[nygge]

I hadn't noticed the introduction of {via,,}. Csaba this seems like a
reasonable way to keep everybody happy.

On Fri, May 23, 2014 at 7:38 AM, Anthony Ramine [email protected]:

You don't seem to use erlang:register directly, and supervisor references
can use the {via,,} values which were specifically introduce to allow
OTP behaviours to use gproc.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-44003725
.

[lucafavatella]

That said, afterwards we added an elarm_registry module, which stores the pids of all elarm servers on the node. That could be used instead of gproc.

@hcs42 I am exploring your proposed solution of using the elarm_registry module (afterwards I plan to analyze the usage of via).

• elarm_registry shall be enriched for keeping track of summary_sups, i.e.:
  • The new function elarm_registry:summary_sup_started(Name) shall be defined, replacing gproc:add_local_name({elarm_summary_sup, Name}))
  • The new function elarm_registry:lookup_summary_sup(Name)shall be defined, replacing gproc:lookup_local_name({elarm_summary_sup, AlarmServer})
  • The state of elarm_registry shall have a new field summary_sups.

At the moment I am not going down this route mainly for https://github.com/jonasrichard/elarm/commit/c69b05840ad9c0dabd9f83b554fdc690cc96a710#commitcomment-6459372.

[nygge]

Why create yet another registry when there is gproc?

On Tue, May 27, 2014 at 10:12 AM, Luca Favatella
[email protected]:

That said, afterwards we added an elarm_registry module, which stores the
pids of all elarm servers on the node. That could be used instead of gproc.

@hcs42 https://github.com/hcs42 I am exploring your proposed solution
of using the elarm_registry module (afterwards I plan to analyze the usage
of via).

• elarm_registry shall be enriched for keeping track of summary_sups,
  i.e.:
  • The new function elarm_registry:summary_sup_started(Name) shall
    be defined, replacing gproc:add_local_name({elarm_summary_sup,
    Name}))
  • The new function elarm_registry:lookup_summary_sup(Name)shall be
    defined, replacing gproc:lookup_local_name({elarm_summary_sup,
    AlarmServer})
  • The state of elarm_registry shall have a new field summary_sups.

At the moment I am not going down this route mainly for
jonasrichard/elarm@c69b058#commitcomment-6459372https://github.com/jonasrichard/elarm/commit/c69b05840ad9c0dabd9f83b554fdc690cc96a710#commitcomment-6459372
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-44289568
.

[lucafavatella]

@nygge We are looking for a solution for registering (locally?) an Erlang process using a term (not a dynamically created atom) without requiring the gproc dependency in order to make elarm easier to handle.

[nox]

I don't get the point of the custom registry. Can't you just allow people to use whatever value allowed by OTP, be it an atom name, a global name or a via tuple?

[hcs42]

Why create yet another registry when there is gproc?

The elarm_registry module was created originally so that:

• There is a possibility of getting the list of all elarm servers.
• There is a possibility to subsrcibe to that list, to be e.g. notified when an elarm server is added.

Can't you just allow people to use whatever value allowed by OTP, be it an atom name, a global name or a via tuple?

To my understanding, the solution with via would still require an Elarm user to have a registry tool, the difference is only that it would be easier to replace gproc with something else. We cannot use the two OTP registries:

• We cannot use "global", because it would sync the names to all nodes.
• We cannot use local registration either, because that works only with atoms, and we don't want to generate them dynamically.

So elarm could work only external dependencies. We could say let's make gproc simply the default – but then the question arises if we put it into our rebar.config file. If no, rebar.config file, the user would need some tinkering to get elarm to work. If yes, that's looks funny, because we will get gproc even when we don't use it, and I'm not sure it make those happy who don't want external dependencies if possible.

What would you use instead of gproc?

[jonasrichard]

About elarm_registry:

When I implemented Wombat elarm integration it came up that there is no information when a new elarm server goes up or goes down, moreover elarm servers can be spawn dynamically. So I needed a solution which can monitor the elarm servers and notifies the external subscribers that: hey, this elarm server has been restarted, please subscribe its alarm notification again.

So the reason was primarily Wombat, but any other external application benefits from that registry.

Richard Jonas
Erlang Solutions Hungary Kft

Address:
Riverpark Office K.32
Közraktár street 32. 3/1.
1093 Budapest
Hungary
Phone/fax:
[phone]

On May 27, 2014, at 5:36 PM, Csaba Hoch [email protected] wrote:

Why create yet another registry when there is gproc?

The elarm_registry module was created originally so that:

There is a possibility of getting the list of all elarm servers.
There is a possibility to subsrcibe to that list, to be e.g. notified when an elarm server is added.
Can't you just allow people to use whatever value allowed by OTP, be it an atom name, a global name or a via tuple?

To my understanding, the solution with via would still require an Elarm user to have a registry tool, the difference is only that it would be easier to replace gproc with something else. We cannot use the two OTP registries:

We cannot use "global", because it would sync the names to all nodes.
We cannot use local registration either, because that works only with atoms, and we don't want to generate them dynamically.
So elarm could work only external dependencies. We could say let's make gproc simply the default – but then the question arises if we put it into our rebar.config file. If no, rebar.config file, the user would need some tinkering to get elarm to work. If yes, that's looks funny, because we will get gproc even when we don't use it, and I'm not sure it make those happy who don't want external dependencies if possible.

What would you use instead of gproc?

—
Reply to this email directly or view it on GitHub.

[nox]

We cannot use local registration either, because that works only with atoms, and we don't want to generate them dynamically.

Why can't users choose the atom name themselves?

[lucafavatella]

Why can't users choose the atom name themselves?

@nox I am working on a patch for enabling almost exactly that, i.e. letting the user decide how the elarm_summary_sup processes should be registered (either {local, Name} or {via, Module, Name} - {global, Name} is discouraged) on a per-process basis. The elarm_summary_sup process for the default alarm server elarm_server will be registered using an atom. Thus the dependency on gproc should be gone.

[lucafavatella]

I believe this issue is fixed by #30 (I used an approach different from the one I had commented above).