[erlang-questions] supervisor_bridge enhancement

[Serge Aleynikov]

I understand that the behavior was introduced as an interop bridge 
between OTP and non-OTP compliant code.  However, as you indicated, in 
that role it has very minimal use these days.  I believe that if it's 
extended with the suggested functionality, it would become more general 
and suitable for solving a broader range of problems (namely - extending 
a server with functionality without changing its code).  This is quite 
convenient when you need to embed some standard OTP application in your 
project and introduce additional functions that are not implemented by 
that application.  In this case the bridge serves as a middle-man 
between the user and the managed OTP app.

Serge

Lennart Öhman wrote:
> Hi Serge,
> I believe you have to high expectations on the supervisor_bridge. It was once developed when OTP was new to accommodate the (then) usual situation that there was non-OTP-compliant code that needed to be ran in a supervision tree. So the superviso_bridge was only meant to handle the OTP-system-message communication between two supervisors. Today there should rarely be any need to use the supervisor_bridge.
> 
> Best regards
> Lennart
> 
> -----Original Message-----
> From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Serge Aleynikov
> Sent: den 24 maj 2008 17:41
> To: Erlang Users' List
> Subject: [erlang-questions] supervisor_bridge enhancement
> 
> Currently the supervisor_bridge behavior doesn't expose
> Mod:handle_call/3 and Mod:handle_info/3 callbacks.  When using this behavior to provide custom startup for some application's server (such as inets' httpd) I frequently find it lacking the ability to report a Pid of the bridged child or provide handling of custom messages.
> 
> Attached is a prototype of supervisor_bridge extension that adds a new function get_child_pid/1, as well as new callbacks Mod:handle_call/3, Mod:handle_cast/2, and handle_info/2.
> 
> Some possible applications of this module could be to implement:
> a. timed instantiation of the bridged Pid (e.g. run the bridged module only between certain hours of a day).
> b. registration of the bridged Pid of a 3rd party server (if it doesn't register itself).
> 
> It would be nice if this supervisor_bridge extension could make it to the distribution.
> 
> Serge
>