Qual é uma boa maneira de escrever um front-end Cocoa para um aplicativo Erlang?

Question

Estou explorando a possibilidade de escrever um aplicativo em Erlang, mas seria necessário ter uma parte escrita em Cocoa (presumivelmente Objective-C).Gostaria que o front-end e o back-end pudessem se comunicar facilmente.Qual a melhor forma de fazer isso?

Posso pensar em usar portas C e processos conectados, mas acho que gostaria de uma situação inversa (o front-end iniciando e conectando-se ao back-end).Existem pipes nomeados (FIFOs), ou eu poderia usar comunicações de rede através de uma porta TCP ou de um soquete BSD nomeado.Alguém tem experiência nesta área?

Answer 1

Uma maneira seria fazer com que o núcleo Erlang do aplicativo fosse um daemon com o qual o front-end do Cocoa se comunica por meio de um soquete de domínio Unix usando algum protocolo simples que você invente.

O uso de um soquete de domínio Unix significa que o daemon Erlang pode ser iniciado sob demanda por launchd e o front-end do Cocoa poderia encontrar o caminho para o soquete a ser usado por meio de uma variável de ambiente.Isso torna o encontro entre o aplicativo e o daemon trivial e também facilita o desenvolvimento de vários front-ends (ou possivelmente uma estrutura que envolva a comunicação com o daemon).

O Mac OS X launchd o sistema é muito legal assim.Se você especificar que um trabalho deve ser iniciado sob demanda por meio de um soquete de domínio Unix seguro, launchd na verdade, criará o próprio soquete com as permissões apropriadas e anunciará sua localização por meio da variável de ambiente nomeada na lista de propriedades do trabalho.O trabalho, quando iniciado, receberá um descritor de arquivo para o soquete por launchd quando faz um simples check-in.

Em última análise, isso significa que todo o processo do front-end abrindo o soquete para se comunicar com o daemon, launchd iniciar o daemon e o daemon que responde à comunicação pode ser seguro, mesmo que o front-end e o daemon sejam executados em níveis de privilégio diferentes.

Answer 2

Uma maneira é a de Theo com NSTask, NSPipe e NSFileHandle.Você pode começar observando o código do CouchDBX http://couchprojects.googlecode.com/svn/trunk/unofficial-binary-releases/CouchDBX/

As portas são possíveis, mas não são nada agradáveis.

Existe alguma razão pela qual esta comunicação não pode ser simplesmente tratada com comunicação mochiweb e json?

Answer 3

Normalmente, ao criar aplicativos Cocoa que enfrentam comandos UNIX ou outros programas headless, você usa um NSTask:

Usando a classe NSTask, seu programa pode executar outro programa como um subprocesso e monitorar a execução desse programa.Um objeto NSTask cria uma entidade executável separada;difere do NSThread porque não compartilha espaço de memória com o processo que o cria.

Uma tarefa opera dentro de um ambiente definido pelos valores atuais de vários itens:o diretório atual, entrada padrão, saída padrão, erro padrão e os valores de quaisquer variáveis ​​de ambiente.Por padrão, um objeto NSTask herda seu ambiente do processo que o inicia.Se houver algum valor que deva ser diferente para a tarefa, por exemplo, se o diretório atual for alterado, você deverá alterar o valor antes de iniciar a tarefa.O ambiente de uma tarefa não pode ser alterado enquanto ela está em execução.

Você pode se comunicar com o processo de back-end por meio de stdin/stdout/stderr.Basicamente NSTask é um wrapper de alto nível em torno exec (ou fork ou system, sempre esqueço a diferença).

Pelo que entendi, você não quer que o programa Erland seja um daemon em segundo plano que roda continuamente, mas se quiser, vá com @Chris sugestão.

Answer 4

As abordagens de soquete de domínio NSTask e Unix são ótimas sugestões.Algo para ficar de olho é uma implementação Erlang FFI que está em andamento:

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

Answer 5

erl_call deve ser utilizável em um NSTask.Eu uso a partir de um comando Textmate e é muito rápido.Combinar erl_call com um OTP gen_server permitiria manter um estado de back-end persistente com relativa facilidade.Veja minha postagem em erl_call no meu blog para mais detalhes.

Answer 6

Usando NSTask você também pode considerar usar PseudoTTY.app (que permite comunicação interativa)!

Outro exemplo de código de interesse poderia ser o BigSQL, um cliente PostgreSQL que permite ao usuário enviar SQL para um servidor e exibir o resultado.

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