Quelle est la bonne façon d'écrire un frontal Cocoa pour une application Erlang ?

Question

J'explore la possibilité d'écrire une application en Erlang, mais il faudrait qu'une partie soit écrite en Cocoa (vraisemblablement Objective-C).J'aimerais que le front-end et le back-end puissent communiquer facilement.Comment y parvenir au mieux ?

Je peux penser à utiliser des ports C et des processus connectés, mais je pense que j'aimerais une situation inverse (le front-end démarre et se connecte au back-end).Il existe des canaux nommés (FIFO), ou je pourrais utiliser les communications réseau via un port TCP ou un socket BSD nommé.Quelqu'un a-t-il une expérience dans ce domaine ?

Answer 1

Une solution serait que le noyau Erlang de l'application soit un démon avec lequel le frontal Cocoa communique via un socket de domaine Unix en utilisant un protocole simple que vous concevez.

L'utilisation d'un socket de domaine Unix signifie que le démon Erlang pourrait être lancé à la demande par launchd et le frontal Cocoa pourrait trouver le chemin d'accès au socket à utiliser via une variable d'environnement.Cela rend le rendez-vous entre l'application et le démon trivial, et facilite également le développement de plusieurs frontaux (ou éventuellement d'un cadre qui encapsule la communication avec le démon).

Le Mac OS X launchd le système est vraiment cool de cette façon.Si vous spécifiez qu'un travail doit être lancé à la demande via un socket de domaine Unix sécurisé, launchd créera en fait le socket lui-même avec les autorisations appropriées et annoncera son emplacement via la variable d'environnement nommée dans la liste des propriétés du travail.Le travail, une fois démarré, recevra en fait un descripteur de fichier au socket par launchd lorsqu'il effectue un simple enregistrement.

En fin de compte, cela signifie que l'ensemble du processus du front-end ouvrant le socket pour communiquer avec le démon, launchd le lancement du démon et le démon répondant à la communication peuvent être sécurisés, même si le frontal et le démon s'exécutent à des niveaux de privilèges différents.

Answer 2

Une solution est celle de Theo avec NSTask, NSPipe et NSFileHandle.Vous pouvez commencer par regarder le code de CouchDBX http://couchprojects.googlecode.com/svn/trunk/unofficial-binary-releases/CouchDBX/

Les ports sont possibles mais pas sympas du tout.

Y a-t-il une raison pour laquelle cette communication ne peut pas être simplement gérée avec la communication mochiweb et json ?

Answer 3

Habituellement, lors de la création d'applications Cocoa qui font face à des commandes UNIX ou à d'autres programmes sans tête, vous utilisez un NSTask:

À l’aide de la classe NSTask, votre programme peut exécuter un autre programme en tant que sous-processus et surveiller l’exécution de ce programme.Un objet NSTask crée une entité exécutable distincte ;il diffère de NSThread en ce sens qu'il ne partage pas d'espace mémoire avec le processus qui le crée.

Une tâche fonctionne dans un environnement défini par les valeurs actuelles de plusieurs éléments :le répertoire actuel, l'entrée standard, la sortie standard, l'erreur standard et les valeurs de toutes les variables d'environnement.Par défaut, un objet NSTask hérite de son environnement du processus qui le lance.Si des valeurs doivent être différentes pour la tâche, par exemple si le répertoire actuel doit changer, vous devez modifier la valeur avant de lancer la tâche.L’environnement d’une tâche ne peut pas être modifié pendant son exécution.

Vous pouvez communiquer avec le processus backend via stdin/stdout/stderr.Fondamentalement NSTask est un wrapper de haut niveau autour exec (ou fork ou system, j'oublie toujours la différence).

Si je comprends bien, vous ne voulez pas que le programme Erland soit un démon d'arrière-plan qui s'exécute en continu, mais si vous le faites, optez pour @Chris suggestion.

Answer 4

Les approches NSTask et Unix domain socket sont toutes deux d’excellentes suggestions.Il faut garder un œil sur une implémentation d'Erlang FFI en cours :

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

Answer 5

erl_call devrait être utilisable à partir d'un NSTask.Je l'utilise depuis une commande Textmate et c'est très rapide.La combinaison de erl_call avec un OTP gen_server vous permettrait de conserver un état backend persistant avec une relative facilité.Voir mon article sur erl_call sur mon blog pour plus de détails.

Answer 6

En utilisant NSTask, vous pouvez également envisager d'utiliser PseudoTTY.app (qui permet une communication interactive) !

Un autre exemple de code intéressant pourrait être BigSQL, un client PostgreSQL qui permet à l'utilisateur d'envoyer du SQL à un serveur et d'afficher le résultat.

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