¿Cuál es una buena manera de escribir una interfaz Cocoa para 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 (presumiblemente Objective-C).Me gustaría que el front-end y el back-end pudieran 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 inicia y se conecta al back-end).Hay canalizaciones con nombre (FIFO), o podría usar 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 demonio con el que el front-end de Cocoa se comunique a través de un socket de dominio Unix utilizando algún protocolo simple que usted diseñe.

El uso de un socket de dominio Unix significa que el demonio Erlang podría iniciarse bajo demanda mediante launchd y el front-end de Cocoa podría encontrar la ruta al socket para usar a través de una variable de entorno.Eso hace que el encuentro entre la aplicación y el demonio sea trivial, y también hace que sea sencillo desarrollar múltiples interfaces (o posiblemente un marco que envuelva la comunicación con el demonio).

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

En última instancia, esto significa que todo el proceso de apertura del socket por parte del front-end para comunicarse con el demonio, launchd iniciar el demonio y que el demonio responda a la comunicación puede ser seguro, incluso si el front-end y el demonio se ejecutan en diferentes niveles de privilegios.

Answer 2

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

Los puertos son posibles pero no son nada agradables.

¿Hay alguna razón por la cual esta comunicación no se puede manejar simplemente con la comunicación mochiweb y json?

Answer 3

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

Usando la clase NSTask, su programa puede ejecutar otro programa como un subproceso y puede monitorear la ejecución de ese programa.Un objeto NSTask crea una entidad ejecutable separada;se diferencia 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, la entrada estándar, la salida estándar, el 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 algún valor que debería ser diferente para la tarea, por ejemplo, si el directorio actual debería 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 backend a través de stdin/stdout/stderr.Básicamente NSTask es un envoltorio de alto nivel alrededor exec (o fork o system, siempre olvido la diferencia).

Según tengo entendido, no desea que el programa Erland sea un demonio en segundo plano que se ejecute continuamente, pero si lo desea, vaya con @Chris sugerencia.

Answer 4

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

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

Answer 5

erl_call debería poder utilizarse desde un NSTask.Yo lo uso desde un comando Textmate y es muy rápido.Combinar erl_call con un OTP gen_server le permitiría mantener un estado de backend persistente con relativa facilidad.Consulte mi publicación sobre erl_call en mi blog para obtener más detalles.

Answer 6

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

Otro código de muestra de interés podría ser BigSQL, un cliente 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