[erlang-patches] new patch: Add plugin support for alternative name lookup

[Ulf Wiger]

Hi Serge,

Sorry for not recalling your suggestion from back then.

It does raise a small question about the whereis_name/2
option. One could simply say that it's up to the callback
to glean any structure from the name - so that 
{via, group, {Group, Name}} would be mapped to 
global_group:whereis_name(Group, Name).

The problem is of course that global_group already has a 
whereis_name/1 that works differently from whereis_name/2.
Since global_group:whereis_name/1 takes a term() as 
argument, it isn't really possible to retroactively introduce a 
special meaning for e.g. {Group, Name}, or even [Group, Name].

So {via, global_group, {Group, Name}} simply wouldn't work,
the way {via, global, Name} works. But as you say, it would
be easy to implement a wrapper around global_group that 
does what you want.

Comments from the OTP team?

BR,
Ulf

On 18 Jan 2011, at 00:58, Serge Aleynikov wrote:

> Ulf,
> 
> Good idea.  At some point I too was running into limitations of current registration options:
> 
> http://www.erlang.org/pipermail/erlang-questions/2008-August/037604.html
> 
> Your approach is more flexible than the patch/solution discussed in that thread.  Though it doesn't negate the need for {global_group, Name}, and {global_group, Where, Name}, which would natively map to the concept of global groups supported by the distribution, the later can be easily implemented using your method.
> 
> +1.
> 
> On 1/17/2011 10:12 AM, Ulf Wiger wrote:
>> 
>> git fetch git://github.com/uwiger/otp.git uw_extending_gen
>> 
>> Note that I've not updated documentation. If people don't
>> like the idea, I won't waste my time doing so, but otherwise, I
>> will follow up with documentation changes as well.
>> 
>> BR,
>> Ulf
>> 
>> 
>> commit 22453671179dadf7204675438cf36edde137f945
>> Author: Ulf Wiger<ulf.wiger@REDACTED>
>> Date:   Mon Jan 17 15:47:00 2011 +0100
>> 
>>     Add plugin support for alternative name lookup
>> 
>>     OTP behaviour instances (gen_server, gen_fsm, gen_event) can currently
>>     register themselves either locally or globally, and the behaviour
>>     libraries (including gen.erl) support both addressing methods, as well
>>     as the normal Pid and {Name, Node}.
>> 
>>     However, there are alternative registry implementations - e.g. gproc -
>>     and one can well imagine other ways of locating a behaviour instance,
>>     e.g. on a node connected only via a TCP tunnel, rather than via
>>     Distributed Erlang. In all these cases, one needs to write extra code
>>     to identify the behaviour instance, even though the instance itself
>>     need not be aware of how it is located.
>> 
>>     This patch introduces a new way of locating a behaviour instance:
>>     {via, Module, Name}.
>> 
>>     Module is expected to export a subset of the functions in global.erl,
>>     namely:
>> 
>>     register_name(Name, Pid) ->  yes | no
>>     whereis_name(Name)  ->  pid() | undefined
>>     unregister_name(Name) ->  ok
>>     send(Name, Msg) ->  Pid
>> 
>>     Semantics are expected to be the same as for global.erl
>> 
>>     This can be used in all places where {global, Name} is accepted.
>> 
>>     In this patch, the test suites gen_server_SUITE, gen_fsm_SUITE and
>>     gen_event_SUITE have been extended, but documentation has not been
>>     updated. This will be done if there is agreement that the idea is
>>     good.
>> 
>> 
>> Ulf Wiger, CTO, Erlang Solutions, Ltd.
>> http://erlang-solutions.com
>> 
>> 
>> 
>> 
>> ________________________________________________________________
>> erlang-patches (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED
>> 
> 
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED
> 

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com