Cuándo usar la aplicación erlang: start o included_applications y un supervisor?
otp rebar (3)
Tener las dependencias declaradas en el descriptor de la aplicación es el camino a seguir, por lo que debe usar la opción B en la mayoría de los escenarios.
El controlador de la aplicación se asegurará de que todas sus dependencias estén presentes e iniciadas (en orden) antes de iniciar su aplicación y también hará que su aplicación falle si esas terminan con errores. Además, el controlador de la aplicación apagará todo cuando sea necesario.
Aparte de eso, si elige la opción A, al iniciar una aplicación con la aplicación: start / 1, obtendrá una aplicación temporal por defecto, por lo que debe usar la aplicación: start / 2, pasando el átomo permanente como segundo argumento.
EDITAR: Tener sus dependencias en el descriptor de la aplicación también ayuda a la visibilidad, es fácil conocer sus detalles sin escanear el código fuente.
Tengo una aplicación Erlang que tiene una dependencia en su directorio deps en otra aplicación.
Por lo que entiendo, puedo tampoco;
a) iniciar mi aplicación dependiente desde mi aplicación incluida llamando a la aplicación: start (some_other_app) que inicia la aplicación y muestra que se ejecuta de forma independiente dentro de Observer.
b) incluir mi aplicación dependiente en mi archivo .app con {included_applications, [some_other_app]} para que la aplicación se cargue y no se inicie y luego iniciar la aplicación incluida desde mi propio supervisor de nivel superior. De nuevo, esto inicia la aplicación incluida y muestra su ejecución debajo de mi propia jerarquía de supervisión en Observer.
Mi pregunta es cuándo debo usar cualquiera de los enfoques? Si uso la opción "a" y mi aplicación dependiente se cierra, ¿se reiniciará o debería utilizar el enfoque "b" para que las dependencias que tengo se supervisen en consecuencia?
En una nota lateral, utilizo Rebar para empacar y administrar mis dependencias.
Gracias,
Andy.
Probablemente no deberías hacer a) ni b)
Mira el capítulo: Aplicaciones incluidas
Cada vez es más recomendable no utilizar las aplicaciones incluidas por una simple razón: limitan seriamente la reutilización de código. Piénsalo de esta manera. Hemos dedicado mucho tiempo a trabajar en la arquitectura de ppool para que todo el mundo pueda usarla, obtener su propio grupo y ser libre de hacer lo que quiera con ella. Si tuviéramos que insertarlo en una aplicación incluida, entonces ya no se puede incluir en ninguna otra aplicación en esta VM, y si erlcount muere, entonces ppool será eliminado, arruinando el trabajo de cualquier aplicación de terceros que desee para usar ppool.
Por estas razones, las aplicaciones incluidas generalmente se excluyen de la caja de herramientas de muchos programadores de Erlang. Como veremos en el siguiente capítulo, los lanzamientos básicamente pueden ayudarnos a hacer lo mismo (y mucho más) de una manera más genérica.
En el capítulo Liberar es la Palabra que puede leer sobre cómo se incluyen varias aplicaciones en una nueva versión y cómo se inician.
Tenía una pregunta similar, ¿cómo se incluyen las dependencias en un proyecto de Erlang y cómo se publican?
Recibí ayuda de varios amigos y de la lista de correo erlang ... y después de volver a leer algunos documentos y más prueba y error ... pensé en algunas cosas. Es largo, así que echa un vistazo a la esencia:
https://gist.github.com/3728780
-Todd