¿Cuál es una buena manera de escribir una interfaz de usuario Cocoa en una aplicación Erlang?

Question

Estoy explorando la posibilidad de escribir una aplicación en Erlang, pero necesitaría tener una parte escrita en Cocoa (supuestamente Objective-C). Me gustaría que el front-end y el back-end puedan comunicarse fácilmente. ¿Cómo se puede hacer esto mejor?

Puedo pensar en usar puertos C y procesos conectados, pero creo que me gustaría una situación inversa (el front-end se inicia y se conecta al back-end). Hay conductos con nombre (FIFO) o podría usar las comunicaciones de red a través de un puerto TCP o un socket BSD con nombre. ¿Alguien tiene experiencia en esta área?

Answer 1

Una forma sería hacer que el núcleo Erlang de la aplicación sea un daemon con el que la interfaz de Cocoa se comunica con un socket de dominio Unix utilizando algún protocolo simple que usted idee.

El uso de un socket de dominio Unix significa que el daemon de Erlang podría iniciarse bajo demanda en launchd y el front-end de Cocoa podría encontrar la ruta de acceso al socket a través de una variable de entorno. Eso hace que la cita entre la aplicación y el daemon sea trivial, y también facilita el desarrollo de múltiples front-ends (o posiblemente un framework que envuelve la comunicación con el daemon).

El sistema Mac OS X launchd es realmente genial de esta manera. Si especifica que un trabajo debe iniciarse bajo demanda a través de un socket seguro de dominio Unix, launchd realmente creará el socket con los permisos apropiados y anunciará su ubicación a través de la variable de entorno nombrada en la lista de propiedades del trabajo. Cuando se inicia el trabajo, en realidad se le pasará un descriptor de archivo al socket al launchd cuando realice un simple check-in.

En última instancia, esto significa que todo el proceso del front-end que abre el zócalo para comunicarse con el daemon, launchd iniciando el daemon, y el daemon que responde a la comunicación puede ser seguro, incluso si el front-end y el daemon ejecutar en diferentes niveles de privilegios.

Answer 2

Por lo general, al crear aplicaciones Cocoa que los comandos frontal UNIX u otros programas sin cabeza se utiliza un NSTask:

Utilización de la clase NSTask, el programa puede ejecutar otro programa como un subproceso y puede supervisar la ejecución de ese programa. Un objeto NSTask crea una entidad ejecutable separada; difiere de NSThread en que no comparte espacio de memoria con el proceso que lo crea.

Una tarea opera dentro de un entorno definido por los valores actuales para varios elementos: el directorio actual, entrada estándar, salida estándar, error estándar y los valores de cualquier variable de entorno. De forma predeterminada, un objeto NSTask hereda su entorno del proceso que lo inicia. Si hay valores que deberían ser diferentes para la tarea, por ejemplo, si el directorio actual debe cambiar, debe cambiar el valor antes de iniciar la tarea. El entorno de una tarea no se puede cambiar mientras se está ejecutando.

Puede comunicarse con el proceso de back-end a través de stdin/stdout/stderr. Bascialmente NSTask es un contenedor de alto nivel alrededor de exec (o fork o system, siempre me olvido la diferencia).

Según tengo entendido, no quiere que el programa Erland sea un daemon de fondo que se ejecuta continuamente, pero si lo hace, vaya con la sugerencia @Chris's.

Answer 3

Una forma es la manera de Theo con NSTask, NSPipe y NSFileHandle. Puede comenzar mirando el código a CouchDBX http://couchprojects.googlecode.com/svn/trunk/unofficial-binary-releases/CouchDBX/

Los puertos son posibles pero no agradables en absoluto.

¿Hay alguna razón para que esta comunicación no pueda ser manejada simplemente con la comunicación mochiweb y json?

Answer 4

Los enfoques de socket de dominio NSTask y Unix son excelentes sugerencias. Algo a tener un ojo en Erlang es una implementación FFI que está en las obras:

http://muvara.org/crs4/erlang/ffi

Answer 5

erl_call debe ser utilizable a partir de un NSTask. Lo uso de un comando de Textmate y es muy rápido. La combinación de erl_call con un OTP gen_server le permitirá mantener un estado de back-end persistente con relativa facilidad. Ver mi publicación en erl_call en mi blog para más detalles.

Answer 6

Usando NSTask también puede considerar usar PseudoTTY.app (que permite la comunicación interactiva)!

Otro código de muestra de interés podría ser BigSQL, un cliente de PostgreSQL que permite al usuario enviar SQL a un servidor y mostrar el resultado.

open -a Safari http://web.archive.org/web/20080324145441/http://www.bignerdranch.com/applications.shtml