Je suis assez d'accord sur XMLRPC mais il faut bien distinguer deux choses :
(1) Le formalisme utilisé pour les trames
(2) Le protocole utilisé pour envoyer et recevoir les trames
XMLRPC n'est qu'un formalisme hérité d'XML, qui lui même est hérité d'un formatage de chaînes de caractères. L'inconvénient de ton approche chaîne/séparateurs est que tu vas très vite être limité lorsque tu voudras faire des choses plus structurées (des paramétres imbriqués par exemple). Le format "chaîne" reste très linéaire.
Pour ce qui est du protocole, rien ne t'empêche de transmettre des requêtes au format XML/RPC via un protocole TCP/IP Raw. Utiliser le protocole HTTP a en revanche l'avantage de pouvoir profiter des infrastructures de proxy et permettre à des applications type HTML/Javascript de communiquer avec le démon.
Je reste donc persuadé que le meilleur compromis est du "XML over HTTP". Maintenant XML/RPC pourquoi pas, mais au fond rien ne t'obliger à prendre cette contrainte.
Maintenant pour ce qui est du temps de réponse, je ne peux raisonner qu'à partir des implémentations que je connais, à savoir en Java. Et dans ce domaine, il ne faut pas ré-inventer la roue. Un conteneur de servlet léger comme Jetty permet très très largement de tenir les contraintes que tu imposes. Généralement lorsque je construit un serveur d'application, ce n'est pas 10 mais 100 utilisateurs concurrent qui attaquent le serveur. Et les temps de réponses sont très faibles car ne correspondent qu'à l'interprétation de la structure XML.
Pour ce qui est de votre travail sur Java, je peux déjà d'expérience vous conseiller une chose : utilisez la plate forme graphique SWT et pas Swing comme je l'ai fait. Les performances seront autrement meilleurs et l'utilisateur final ne verra pas d'un point de vue visuel pas la différence avec une application "standard", tout en restant multi-plateforme (cela utilise le toolkit natif au lieu de tout redessiner en Java). Pour le reste, cela tombe plutôt bien car je compte moi laisser tomber mon système de gadget me disant que j'allais plutôt profiter du votre et me concentrer sur l'API.
Maintenant si vous compter re-écrire votre API en java, dites le moi assez tôt, car ce ne serait du coup pas la peine que je mette la mienne à jour
Je suis assez d'accord sur XMLRPC mais il faut bien distinguer deux choses :
(1) Le formalisme utilisé pour les trames
(2) Le protocole utilisé pour envoyer et recevoir les trames
XMLRPC n'est qu'un formalisme hérité d'XML, qui lui même est hérité d'un formatage de chaînes de caractères. L'inconvénient de ton approche chaîne/séparateurs est que tu vas très vite être limité lorsque tu voudras faire des choses plus structurées (des paramétres imbriqués par exemple). Le format "chaîne" reste très linéaire.
Pour ce qui est du protocole, rien ne t'empêche de transmettre des requêtes au format XML/RPC via un protocole TCP/IP Raw. Utiliser le protocole HTTP a en revanche l'avantage de pouvoir profiter des infrastructures de proxy et permettre à des applications type HTML/Javascript de communiquer avec le démon.
Je reste donc persuadé que le meilleur compromis est du "XML over HTTP". Maintenant XML/RPC pourquoi pas, mais au fond rien ne t'obliger à prendre cette contrainte.
Maintenant pour ce qui est du temps de réponse, je ne peux raisonner qu'à partir des implémentations que je connais, à savoir en Java. Et dans ce domaine, il ne faut pas ré-inventer la roue. Un conteneur de servlet léger comme Jetty permet très très largement de tenir les contraintes que tu imposes. Généralement lorsque je construit un serveur d'application, ce n'est pas 10 mais 100 utilisateurs concurrent qui attaquent le serveur. Et les temps de réponses sont très faibles car ne correspondent qu'à l'interprétation de la structure XML.
Pour ce qui est de votre travail sur Java, je peux déjà d'expérience vous conseiller une chose : utilisez la plate forme graphique SWT et pas Swing comme je l'ai fait. Les performances seront autrement meilleurs et l'utilisateur final ne verra pas d'un point de vue visuel pas la différence avec une application "standard", tout en restant multi-plateforme (cela utilise le toolkit natif au lieu de tout redessiner en Java). Pour le reste, cela tombe plutôt bien car je compte moi laisser tomber mon système de gadget me disant que j'allais plutôt profiter du votre et me concentrer sur l'API.
Maintenant si vous compter re-écrire votre API en java, dites le moi assez tôt, car ce ne serait du coup pas la peine que je mette la mienne à jour