En fait, l'exemple de macro est un format interprété par les 2 librairies. Tout ceci se passe avant la "daemonization". Le serveur web est juste un petit truc que j'ai fait pour voir comment une page web pouvait éxécuter une commande sur le robot. J'en suis arriver à un truc du style "http://127.0.0.1/send.html?command=TUX_CMD:WINGS:OPEN". Je sais que je ne suis pas toujours très clair dans ce que je dis lol.
En gros tout ce qu'on peut commander ou recevoir de tux est formaté dans des strings. Ce qui offre l'avantage de pouvoir être compatible avec tout système et tout langage.
En ce qui concerne la future communication entre le daemon et la future api, j'hésite encore beaucoup. Le deamon son qui se trouve actuellement dans nos packages, a une interface XMLRPC. Ce qui fait que tuxd est en TCPIP et le son en XMLRPC. La semaine passée, j'ai fait une petite démo avec un groupe d'étudiants, et je me suis rendu compte qu'avec une 20ène de pc connectés sur les mêmes daemon, les commandes TTS (donc en client xmlrpc) était nettement plus lente. Cela bloquait très souvent et ça a même fini par planter ... Maintenant, c'est peut-être mon implémentation qui n'est pas bonne ...
A priori, le protocol xmlrpc est quand même plus lourd que du simple tcpip. D'autant plus qu'en tcpip on reste connecté, et je pense qu'avec le rapatriement des status du robots qui peuvent arriver toutes les 100 msec, une connexion de type xmlrpc ne soit pas approprié (pour une question de temps réel) (Le future système devra supporter autant de connexions clientes que de soft/gadgets à utiliser tux)
Ce que je me dis aussi, c'est que comme tout passe par des strings maintenant, le fait d'utiliser un protocol basic ne soit plus un problème.
Maintenant cela demande réflexion, et je n'arrive pour le moment pas à trancher.
Finalement, les contraintes sont simples:
Doit pouvoir supporter:
- Un nombre de clients > 10
- Un débit assuré ~100msec
- Un interfaçage ultra standard
En ce qui concerne une collaboration, j'ai pas encore les idées claires lol, mais tu as travaillé sur un système de gadgets, sur une api, et en plus en java. Hors, nous là, on est entrain de partir sur du java Un collègue étudie pour le moment la question du skinning, webbrowser, etc ... en java, dans le but de faire un manager de gadget à la itunes ou songbird.
De toutes manière, je vais encore discuter avec toi. Là je dois reprendre ce que j'étais entrain de faire.
En fait, l'exemple de macro est un format interprété par les 2 librairies. Tout ceci se passe avant la "daemonization". Le serveur web est juste un petit truc que j'ai fait pour voir comment une page web pouvait éxécuter une commande sur le robot. J'en suis arriver à un truc du style "http://127.0.0.1/send.html?command=TUX_CMD:WINGS:OPEN". Je sais que je ne suis pas toujours très clair dans ce que je dis lol.
En gros tout ce qu'on peut commander ou recevoir de tux est formaté dans des strings. Ce qui offre l'avantage de pouvoir être compatible avec tout système et tout langage.
En ce qui concerne la future communication entre le daemon et la future api, j'hésite encore beaucoup. Le deamon son qui se trouve actuellement dans nos packages, a une interface XMLRPC. Ce qui fait que tuxd est en TCPIP et le son en XMLRPC. La semaine passée, j'ai fait une petite démo avec un groupe d'étudiants, et je me suis rendu compte qu'avec une 20ène de pc connectés sur les mêmes daemon, les commandes TTS (donc en client xmlrpc) était nettement plus lente. Cela bloquait très souvent et ça a même fini par planter ... Maintenant, c'est peut-être mon implémentation qui n'est pas bonne ...
A priori, le protocol xmlrpc est quand même plus lourd que du simple tcpip. D'autant plus qu'en tcpip on reste connecté, et je pense qu'avec le rapatriement des status du robots qui peuvent arriver toutes les 100 msec, une connexion de type xmlrpc ne soit pas approprié (pour une question de temps réel) (Le future système devra supporter autant de connexions clientes que de soft/gadgets à utiliser tux)
Ce que je me dis aussi, c'est que comme tout passe par des strings maintenant, le fait d'utiliser un protocol basic ne soit plus un problème.
Maintenant cela demande réflexion, et je n'arrive pour le moment pas à trancher.
Finalement, les contraintes sont simples:
Doit pouvoir supporter:
- Un nombre de clients > 10
- Un débit assuré ~100msec
- Un interfaçage ultra standard
En ce qui concerne une collaboration, j'ai pas encore les idées claires lol, mais tu as travaillé sur un système de gadgets, sur une api, et en plus en java. Hors, nous là, on est entrain de partir sur du java
Un collègue étudie pour le moment la question du skinning, webbrowser, etc ... en java, dans le but de faire un manager de gadget à la itunes ou songbird.
De toutes manière, je vais encore discuter avec toi. Là je dois reprendre ce que j'étais entrain de faire.
Rémi