Re: add application:start_all/1-2 (recursive OTP app starting)

+1


On Thu, Jul 11, 2013 at 3:22 AM, Siri Hansen <[email protected]> wrote:

> Hi Fred!
>
> OTP technical board has discussed your patch and we find the functionality
> useful. We would, however, like to see some adjustments:
>
> 1. Since the function behaves more like application:ensure_started/1,2
> than application:start/1,2 we would like the new name to be
> ensure_all_started/1,2.
>
> 2. On failure, the current implementation potentially leaves one or more
> applications started. We would like it to clean up after itself in this
> situation.
>
> 3. On success, we would like the function to return {ok,StartedApps},
> where StartedApps is the list of applications (names) that were actually
> started.
>
> Would it be possible for you to update the patch accordingly?
>
> Thanks for your contribution!
> Regards
> /siri
>
>
>
> 2013/6/24 Fredrik <[email protected]>
>
>> On 06/20/2013 08:16 PM, Fred Hebert wrote:
>>
>>> This adds two new functions to the application module that will
>>> recursively look for missing dependencies to start the entire dependency
>>> chain of a given application, and then the application itself, if
>>> possible.
>>>
>>> Its entire behavior is based on the currently existing 'start/1-2'
>>> functions, which will report dependencies that have not yet been started
>>> and other problems encountered. 'start_all/1-2' will use this
>>> information the way any programmer would manually do it to automate the
>>> process.
>>>
>>> This kind of functionality, while not OTP-ish (releases do this start
>>> sequence for the user), is still useful for testing purposes, quick
>>> demonstrations, and programmers who do not wish or know how to use OTP
>>> releases.
>>>
>>> The function returns 'ok' for all started or already started
>>> applications, and will return '{error, {AppName, Reason}}' on a failure
>>> to allow users to rapidly know why the function failed.
>>>
>>> I decided to call it start_all even though its semantics are somewhat
>>> similar to ensure_start in how it ignores already_started applications,
>>> but am open to changing the name if the OTP team prefers
>>> 'ensure_all/1-2' as functions for this module.
>>>
>>> Documentation has been added, and so were tests, looking for a few
>>> simple case: simple app, app with a dependency, and apps with a
>>> 3rd-level dependency not booting, all locally.
>>>
>>> Note that no specific check is made for direct or indirect circular
>>> dependencies between applications, and these will make the function go
>>> in an infinite loop.
>>>
>>> git fetch git://github.com/ferd/otp.git start-all
>>>
>>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all<https://github.com/ferd/otp/compare/erlang:maint...start-all>
>>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all.patch<https://github.com/ferd/otp/compare/erlang:maint...start-all.patch>
>>>
>>> Regards,
>>> Fred Hebert.
>>> ______________________________**_________________
>>> erlang-patches mailing list
>>> [email protected]
>>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>>
>> Hello Fred,
>> I've fetched your patch and assigned it to be reviewed.
>> Thanks,
>>
>> --
>>
>> BR Fredrik Gustafsson
>> Erlang OTP Team
>>
>>
>> ______________________________**_________________
>> erlang-patches mailing list
>> [email protected]
>> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>>
>
>
> _______________________________________________
> erlang-patches mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-patches
>
>


-- 
/* Sincerely
--------------------------------------------------------------
Pedram Nimreezi - Chief Technology Officer  */

// The hardest part of design … is keeping features out. - Donald Norman

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches