Qual è un buon modo per scrivere un front-end Cocoa per un'applicazione Erlang?

Question

Sto esplorando la possibilità di scrivere un'applicazione in Erlang, ma sarebbe necessario avere una parte scritta in Cocoa (presumibilmente Objective-C).Mi piacerebbe che il front-end e il back-end fossero in grado di comunicare facilmente.Come è possibile farlo al meglio?

Posso pensare di utilizzare porte C e processi connessi, ma penso che mi piacerebbe una situazione inversa (il front-end si avvia e si connette al back-end).Esistono pipe denominate (FIFO), oppure potrei utilizzare le comunicazioni di rete su una porta TCP o un socket BSD denominato.Qualcuno ha esperienza in questo settore?

Answer 1

Un modo potrebbe essere quello di fare in modo che il core Erlang dell'applicazione sia un demone con cui il front-end Cocoa comunica su un socket di dominio Unix utilizzando un semplice protocollo ideato dall'utente.

L'uso di un socket di dominio Unix significa che il demone Erlang può essere lanciato su richiesta da launchd e il front-end Cocoa potrebbe trovare il percorso del socket da utilizzare tramite una variabile di ambiente.Ciò rende banale l'incontro tra l'app e il demone e semplifica anche lo sviluppo di più front-end (o eventualmente un framework che integri la comunicazione con il demone).

Il Mac OS X launchd il sistema è davvero fantastico in questo modo.Se specifichi che un lavoro deve essere avviato su richiesta tramite un socket di dominio Unix sicuro, launchd creerà effettivamente il socket stesso con le autorizzazioni appropriate e ne pubblicizzerà la posizione tramite la variabile di ambiente denominata nell'elenco delle proprietà del lavoro.Al lavoro, una volta avviato, verrà effettivamente passato un descrittore di file al socket launchd quando fa un semplice check-in.

In definitiva ciò significa che l'intero processo di apertura del socket da parte del front-end per comunicare con il demone, launchd l'avvio del demone e il demone che risponde alla comunicazione possono essere sicuri, anche se il front-end e il demone vengono eseguiti con livelli di privilegi diversi.

Answer 2

Un modo è quello di Theo con NSTask, NSPipe e NSFileHandle.Puoi iniziare guardando il codice di CouchDBX http://couchprojects.googlecode.com/svn/trunk/unofficial-binary-releases/CouchDBX/

I porti sono possibili ma non sono affatto carini.

C'è qualche motivo per cui questa comunicazione non può essere gestita semplicemente con la comunicazione mochiweb e json?

Answer 3

Di solito quando si creano applicazioni Cocoa che fronteggiano comandi UNIX o altri programmi headless si utilizza un file NSTask:

Utilizzando la classe NSTask, il tuo programma può eseguire un altro programma come sottoprocesso e monitorare l'esecuzione di quel programma.Un oggetto NSTask crea un'entità eseguibile separata;differisce da NSThread in quanto non condivide lo spazio di memoria con il processo che lo crea.

Un'attività opera all'interno di un ambiente definito dai valori correnti per diversi elementi:la directory corrente, l'input standard, l'output standard, l'errore standard e i valori di qualsiasi variabile d'ambiente.Per impostazione predefinita, un oggetto NSTask eredita il suo ambiente dal processo che lo avvia.Se sono presenti valori che dovrebbero essere diversi per l'attività, ad esempio se la directory corrente dovesse cambiare, è necessario modificare il valore prima di avviare l'attività.L'ambiente di un'attività non può essere modificato mentre è in esecuzione.

Puoi comunicare con il processo di backend tramite stdin/stdout/stderr.Fondamentalmente NSTask è un wrapper di alto livello exec (O fork O system, dimentico sempre la differenza).

A quanto ho capito, non vuoi che il programma Erland sia un demone in background che funziona continuamente, ma se lo fai, vai con @Chris suggerimento.

Answer 4

Gli approcci con socket di dominio NSTask e Unix sono entrambi ottimi suggerimenti.Qualcosa da tenere d'occhio è un'implementazione di Erlang FFI in lavorazione:

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

Answer 5

erl_call dovrebbe essere utilizzabile da un NSTask.Lo uso da un comando Textmate ed è molto veloce.La combinazione di erl_call con un gen_server OTP ti consentirebbe di mantenere uno stato di backend persistente con relativa facilità.Vedi il mio post su erl_call nel mio blog per maggiori dettagli.

Answer 6

Utilizzando NSTask potresti anche prendere in considerazione l'utilizzo PseudoTTY.app (che consente la comunicazione interattiva)!

Un altro esempio di codice interessante potrebbe essere BigSQL, un client PostgreSQL che consente all'utente di inviare SQL a un server e visualizzare il risultato.

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