Connexion utilisateur
Sommaire
Du même tonneau
Commentaires récents
  • Ulhume: Hi Cristina, Sorry but this API is not maintained any more
  • Cristina: Hi hi! I speak a very little little little french but correct
  • Non2: Merci. Grâce à vos explications claires (c'est rare), j'ai pu
  • Ulhume: @Nioub vachement intéressant, merci !!
  • Nioub: Un article d'IBM est récemment sorti:
Navigation
Syndication
 
Tutoriel
L'art de faire manger des fichiers WAV à TuxDroid
Le 5 octobre 2007, à 4:31 par Ulhume...

Grande bataille de gagnée ce soir... (euh... ce matin en fait, j'va être ben frai moi pour bosser Smiling J'ai enfin réussi à enregistrer des sons dans cette maudite mémoire interne du TuxDroid. Oui je sais, j'occupe certaines de mes nuits étrangement... Mais une fois que je tiens un morceau, j'ai du mal à le lacher...

Car je ne veux pas critiquer les devs du pingouin mécanique, mais y'a du réellement vaudou là dessous... Je suis pas sur d'avoir bien compris... En fait pour stocker N sons dans le tux, il faut (attention, on s'accroche) :

  1. Lire le "sample rate" de chaque fichier audio. Information contenue dans le header du fichier wav (qui est constitué de 44 octets), sur 4 octets, en position 24.
  2. Si le sample rate n'est pas très exactement de 8khz, il faut convertir le sample avec la commande sox source.wav -c 1 -r 8000 -b cible.wav.
  3. Il faut ensuite regarder en position 40, la taille de la "charge utile" codé sur 4 octets. Chose étrange, le chiffre est inférieur à la réalité, c'est à dire tailleFichier-44.
  4. Ensuite il faut merger tous les wav's en un seul. Pour cela, on récupère le header du premier wave, sauf la taille (40 octets donc, faut suivre Wink. On réserver 4 octets (pour la futur taille) et on ajoute à la queue leu-leu tes charges utiles (tout sauf les 44 premiers octets) de chacun des samples.
  5. Et là commence le vaudou, le naïf aurait pu croire qu'il faille insérer la taille avec la somme de toutes les tailles... Oui mais non... En fait il faut insérer tailleDansHeader=sommeTailles+0.07*sommeTailles (au petits malin qui veulent factoriser, je rappelle que l'on est en arithmétique entière Wink. Pourquoi .07 ? aucune idée...
  6. Bref, on insère la valeur ainsi trouvée et on se dit c'est fini. Ben non, car tant que la taille physique du fichier est inférieur à tailleDansHeader-44, on ajoute 12 espaces à la suite des données !!!
  7. C'est pas fini, il faut ensuite réinitialiser la mémoire du tux, pour cela, on s'accroche, il faut d'abord envoyer la commande qui indique au Droid le nombre de sample qui vont arriver.
  8. On attends 10 secondes !!!
  9. On envoi à Tux un premier index en 0x400... Pourquoi, je sais pas, c'est comme si on définissant un premier sample "blanc"
  10. Puis on envoi les N indexes suivant, en incrémentant à chaque fois avant de la taille (la vraie, celle du header d'origine) du sample en prenant bien soin de faire une pause de 100ms entre chaque envois...
  11. Enfin, pour ceux qui se demandaient comment envoyer les données elles-même au Tux, ben c'est tout con, on envoi notre super WAV précédemment fusionné... dans la carte son USB avec un aplay -D hw:0,0 merged.wav...

J'avoue que je ne m'attendait pas à un truc aussi délirant.. Je subodore que le coup de 0.07 et du padding avec des espaces à la fin permet au firmware de comprendre qu'il doit arrêter de stocker...
Peu importe, aidé du code python de l'API d'origine et de celui de tuxgi, on y arrive. Mais serieux, c'est pas clair du tout à lire le Python...

En tout cas pour ceux qui veulent savoir comment la même chose peut maintenant être réalisée en Java :

  1. WaveFile[] files = new WaveFile[4];
  2. files[0] = new WaveFile("./r2d2wst1.wav");
  3. files[1] = new WaveFile("./saberon.wav");
  4. files[2] = new WaveFile("./hyperdrv.wav");
  5. files[3] = new WaveFile("./beamup.wav");
  6. tux.sound().store(files);

C'est sur, une fois que le gros est caché dans l'API, c'est plus simple Smiling A noter que l'objet WaveFile converti tout seul les samples au bon format.

Ban ben vala, je suis content, j'ai saoulé tout le monde, je vais me coucher Smiling

Commentaires

jaguarondi, le 15 October, 2007 - 21:06

S#!$ j'avais fait one longue réponse hier et elle n'est pas passée, j'ai un peu de mal à faire passer le test du vilain spammeur à Opéra, si je publie directement, l plupart du temps ma réponse est fausse. Je dois être vraiment très mauvais en lecture de chiffres.

Sionon j'expliquais que le gars qui a fait la RF et tuxaudio (dont la gestion de la flash) est parti et je reprends ses codes. Et ce que tu décris là m'a bien fait rire, c'est typique de sa façon de programmer. Enfin, y'a du boulot quoi.

Juste pour t'expliquer 2,3 trucs si je me souviens bien, l'écriture dans la flash utilise le même canal RF que quand on envoie du son au HP. Et tant que l'index de fin n'est pas atteint, elle attend les échantillons, pas de timeout ni gestion d'erreur, rien. Donc si la RF perd quelques trames, ton tux est bloqué. Pour contrer ça, la solution (très très élégante) a été de rajouter du blanc à la fin des samples, donc si des échantillons sont perdus, le début d'un son se retrouve à la fin du précédent mais au moins ça ne bloque pas. Ca doit expliquer le 0.07 et le blanc quelque part.

Les 10 secondes, c'est pour attendre l'effacement de la flash. Ca prends moins de temps que ça en général, mais comme on n'a aucun feedback, on attend. Qu'est-ce qu'on ne ferait pas pour la beauté de l'implémentation Wink

0x400, ça doit être l'index du premier échantillon, le début de la flash étant réservé pour les indexes.

Enfin, j'espère que ça t'aidera un peu. La prochaine fois contacte moi (par email ou autre) et j'essaierai de t'aider au mieux pour t'éviter de perdre du temps pour des bêtises. Sinon on a prévu de revoir la programmation de la flash pour améliorer ça, mais je ne sais pas quand on aura le temps de le faire.

A+,
David

Ulhume, le 16 October, 2007 - 00:02

Bon, ben maintenant ça ne devrait plus poser de problème, plus de devinette. Ceci dit, tu peux aussi créer un compte Wink Tongue

Sinon, je comprends mieux la tête du code. T'inquiètes je suis autant chef de projet que développeur, ça ne me choque pas deux secondes Wink Je me vois encore passer des heures à expliquer à quoi peuvent servir des tests unitaires...

En tout cas je vois mieux le coup des blancs et des délais. Ceci dit y'avais pas moyen d'uploader cela comme une commande ? C'était peut-être un peu moins risqué comme méthode, non ? C'est sûrement ce que tu veux dire par "programmation de la flash".

Ok, la prochaine fois, je galère pas comme une bête, je te contacte Smiling Là je suis déjà content ça passe à tout les coups chez moi et le tux est pour le coup transformé en R2D2 au démarrage Wink

C'est tout de même marrant ce truc, j'aurais jamais cru que développer pour cette bestiole soit aussi "large spectre", et encore je ne touche qu'à l'API, pas au firmeware. Rien que pour le threading c'est un vrai roman.

Jaguarondi , le 16 October, 2007 - 09:00

Compte créé Smiling
Les tests unitaires, j'en suis convaincu et j'essaie de faire un équivalent en firmware (beaucoup moins évident) lorsqu'on développe un nouveau module, on fait un programme de test du module. Sinon mon cheval de bataille, ça a été tout un moment SVN, et c'est un échec pour la plupart. Moi je passe à du décentralisé (bazaar, ou mercurial ou GIT) et là je ne pense même pas un jour l'expliquer. D'ailleurs, si tu veux tu peux utiliser le svn de tuxisalive pour ton développement si ça t'intéresse.

Un truc qui m'intéresse, puisque tu est en plein dans l'api et l'utilisation de tux, ça te semble logique l'architecture de l'api et la communication daemon/api? Mais j'ai pas d'expérience en tcp/ip, ni grand chose côté PC, j'ai commencé un peu de lecture sur l'OO et je trouve ça passionnant. Mais je ne retrouve pas grand chose de structuré dans l'API, mais comme je n'y connais rien, ça serait bien d'avoir l'avis d'autres.

Ulhume, le 16 October, 2007 - 09:41

Ahh les tests unitaires. Dans le monde java si tu n'utilises pas c'est deux claques Wink Pour les autres langages (Genre Delphi... grrr) c'est vrai que c'est moins simple même si les équivalents de JUnit se sont développés un peu partout.

Pour SVN (et avant lui CVS) l'imposer chez nous (SSII) a été un vrai squetch (comme les tests unitaires, les normes de codage et l'audit automatisé de qualité de code d'ailleurs). Aujourd'hui il semble que ce soit rentré un peu plus dans les moeurs. Pour GIT & Co. j'ai pas encore testé, j'avais lu avec interêt les argumentaires de Torvald sur le sujet sans pour autant me lancer dans l'aventure. SVN me va très bien pour l'instant et même les projets libres auquels je participe ne dépasse que rarement... 2 personnes Wink))

Pour le SVN de TuxIsAlive je te remercie de ton offre mais pour l'instant j'ai déjà un serveur fonctionnel. En revanche, si l'API intéresse des gens (c'est pas encore gagné Wink cela serait pertinent de mirrorer les updates dessus pour plus de simplicité.

Pour répondre à ta question sur l'API je vais couper mon analyse en trois volets : protocole, logique et API python.

Aspect protocolaire

Les démons, tel que je les comprend, forment une sorte de "middleware". A ce titre, leur rôle n'est que de créer une abstraction "moyen-niveau" en convertissant de l'USB bas-niveau en accès TCP/IP-socket. De ce point de vue c'est très bien. Cela permet de l'attaquer par n'importe quel langage (tous ont un accès socket, moins un accès natif usb).

Le "hic" c'est qu'en restant au simple client/serveur TCP/IP, vu du côté API, c'est très très mais alors très "old faschion". Tant qu'à créer une abstraction, il aurait été sans doute plus pertinent d'adopter un formalisme type XML/WebServices sur une base protocole type HTTP. Cette approche permettrait :

  1. de simplifier énormement le code des API en évitant toutes ces magouilles de cmd_struct & co. Tout en restant proche du système d'origine et doncd léger, les commandes et réponses seraient plus lisibles, facile à interpréter, sans cas particuliers.
  2. de permettre une ouverture encore plus large à des techniques type "Ajax". En effet, le démon étant un serveur TCP/IP, s'il passe au stade au dessus et adopte un protocole HTTP/XML, se rend visible par des applications web dynamiques (Ajax). Sonny (un autre contributeur) pourrait ainsi faire une application FireFox qui contrôle le Tux. Pour l'instant, c'est impossible.

Logique interne du démon

Je ne sais pas ce que fait réellement le démon mais s'il se contente de convertir les "ordres" TCP/IP en "ordre" usb, pas de soucis.

En revanche, ce que je crains, s'il y a une logique interne en plus (comme gérer des compteurs, ou des états), là c'est un "problème" car il y a d'un point de vue fonctionnel cela fait un doublon avec l'API et un risque de complexité => des bugs potentiels. Les démons, pour moi doivent et doivent seulement jouer le rôle d'abstraction de l'usb bas niveau.

L'API python existante

Concernant l'API python elle-même, elle est du coup très proche de la philosophie du démon, d'où ton impression de "non structuration". Elle colle à la structure des trames et utilise les objets comme des "classeurs" de commandes.

La valeur ajoutée de l'API est du coup assez faible, c'est juste une nouvelle traduction du protocole bas niveau.

Si tu regardes le JavaDoc de l'API java, j'ai opté pour une philosophie transversale à celle-ci. L'objet n'est alors pas utilisé pour "classer" les fonctions du Tux mais pour, lui aussi, créer une abstraction, objet, du Tux faisant oublier (du moins j'espère Wink la mécanique interne réelle. Cela donne des trucs du genre :

  1. Tux tux = new Tux("localhost");
  2. tux.eyeLeads().openBoth();
  3. tux.iris().switchBothOn();
  4. tux.waitPreviousCommands();
  5. tux.wings().flap();
  6. tux.speak("Hello world");  

En conclusion pour moi, la raison d'être du démon est seulement de créer une abstraction USB/réseau et son évolution intéressante serait de gérer proprement et de manière moderne un protocole réseau type HTTP/XML normalisé (XmlRPC ou WebServices). S'il inclut de la logique interne supplémentaire, il fait doublon avec l'API.

J'espère que tout ce que je racontes n'est pas trop "confu" et que cela va aider.

jaguarondi, le 16 October, 2007 - 10:20

Super intéressant. En fait moi, en abordant le daemon par le firmware et l'USB, je le vois également comme une abstraction de l'USB mas également du fonctionnement du hardware. Exemple, la mesure de lumière est un peu complexe, la mesure comprend la valeur de 10 bits et 1 bit qui indique si on est en mode basse ou haute lumière. En gros, si la lumière passe de rien (noir) à très forte (soleil), la mesure va de 0 à un peu plus de 1000 en mode basse lumière puis on atteint le seuil où on pass en mode haute lumière et la valeur retombe à disons 200 et remonte jusque 1024. Dans le daemon, on recompose ça pour n'avoir qu'une valeur de lumière qui évolue très approximativement de façon linéaire et varie de 0 à 1128, c'est l'abstraction du fonctionnement interne des capteurs. Pareil, si pour passer en mode sleep, il faut envoyer une série de commandes successives, l'API doit être simple et le daemon décompose la fonction sleep en ce qui est nécessaire.
Par exemple pour récupérer les versions des différents processeurs, est-ce que ce ne serait pas le daemon qui devrait questionner les procs tour à tour et garder les versions dans une structure qui serait simplement retournée au client (api python ou java) quand il le demande?
Pour les statuts de tux, je trouve qu'il y a des trucs qui ont plus de sens que la valeur de tous les bits des I/O des processeurs. Le statut CHARGEUR pourrait simplement être dans plusieurs états, et le daemon s'occuperait de déterminer l'état en fonction de tous les bits (pluggé, en charge, fin de charge, pas de tension si le transfo n'est pas branché dans la prise, ...). L'intérêt, c'est vraiment de faire abstraction du hardware au niveau daemon. Cela faciliterait le développement de clients dans plusieurs languages puisque les specs dprotocole du daemon se simplifieraient.

En fait, tu es le premier à te lancer à traduire l'api python vers autre chose, mais moi ça me semble assez infaisable. En tout cas je me dis qu'il doit y avoir plus simple dans la structure et répartition des tâches entre le daemon et l'api pour qu'on puisse facilement la porter vers d'autres languages. Et pour moi déplacer tout ce qui est gestion du hardware dans le daemon est une simplification. Maintenant est-ce qu'il n'y a pas des méthodes pour générer des bindings d'un language vers un autre? Ou c'est mieux d'écrire l'api dans tous les languages?

Pour aller encore plus loin, je me demandais si des trucs comme détection d'un claquement de main ou d'un niveau de bruit ne pourrait pas également être fait par le daemon pour enrichir les statuts et ne pas devoir faire ce traitement dans tous les languages.

Enfin bon, c'est probablement pas très clair mais c'est un premier jet Wink , la discussion est intéressante en tout cas

Ulhume, le 16 October, 2007 - 10:58

Ton approche est juste, le démons doit être une abstraction protocole (USB) et hardware. Mais comme toujours la frontière est mince. Par exemple (je ne sais pas si c'est le cas même si je me doute). Les fonctions Open et Close sont pour moi de l'ordre du haut niveau (API) et n'ont rien à faire dans le démon. En revanche, la bufferisation des status, elle, me parrait plus du domaine du démon avec un process du type:

 - État présente dans le buffer ? 
    - Non, faire la requête au hardware, attendre la réponse (cf process suivant)
 - Revoyer la valeur à l'API

et d'un autre côté dans la boucle de démon

  - Réception d'un status du hardware 
    - mettre en buffer
    - envoyer la commande de retour status à l'API

Ca, ca simplifierait gravement l'API pour un job qui n'est pas vraiment le sien. En gros, pour compléter ce que je disais avec ce que tu viens d'ajouter, de démon est :

  1. une abstraction protocole qui a tout a gagner à passer en HTTP/XML
  2. Une abstraction hardware qui cache/simplifie sa mécanique mais qui n'ajoute pas de nouvelle fonctions.

Ainsi tu aurais une approche "propre":

USB (pour simplifier)
Coucherôlesortie
Hardware-
DémonsAbstraction du hard (Agrégation/buffer/simplification)HTTP/XML
API/ClientFonction haut niveau-

Pour ce qui est de la simplification des bindings, oui, il y a une méthode. Elle consiste à écrire une API non pas en python mais en C/C++. Ainsi tu peux générer un bind quasi automatique des headers vers les langages cibles. L'erreur serait à mon sens de fusionner cette idée avec celle du démon qui ne doit pas sortir du périmètre dont nous parlons. Mais sorti de là, une lib/API en C va pouvoir servir de graine à toute une génération de bindings sans grands efforts.

Après cela n'empêche pas de faire des API "full XXX" comme la mienne en Java, tu ouvres les possibles, tu ne les fermes pas. Dans la même idée, plus rien n'empêche des lors de que l'on dispose d'un démon et d'une Lib/API de faire de l'hybridage. Par exemple ton claquement de mains trouvera sa place très logiquement dans la lib que mon API peut utiliser, ou pas. Si en java je dispose de fonctions de reconnaissance audio plus avancées, je ne suis dés lors pas bloqué pour les utiliser. Si tu le place au niveau du démon, c'est moins sur.

En effet, c'est très intéressant, mais ce Tux EST intéressant car il est un labo en miniature d'une myriade de techniques et concepts complexes. Le portage en Java n'a certes pas été simple mais très instructif, ça s'est sur.

Jaguarondi , le 16 October, 2007 - 11:18

Bon ben on s'approche d'un truc qui me plaît vraiment là. Je termine de tester la RF et faire mon rapport sur le wiki, puis je vais nettoyer les statuts et commandes supportées par tux et faire une proposition de ce que le daemon devrait supporter et on en rediscute Smiling

J'avais déjà lu une petite intro à XML/RPC, je vais m'y remettre un peu et regarder webservices alors.

Ulhume, le 16 October, 2007 - 11:31

Ok avec plaisir.

Pour le XML/RPC, entre nous, tu risques de mourir à essayer de supporter quelque chose de réellement standard. Un protocole XML "maison" est largement suffisant à mon sens.

Rémi Jocaille , le 5 April, 2008 - 14:52

Salut,
Je crois que tu as passé assez de temps dans le code de l'API pour savoir qui je suis lol.
Je vais un peu m'expliquer sur l'architecture du système telle que tu la vu dans la version courrante de l'API, puis je te parlerai du système v2 que je suis en train de développer.
Tout d'abord, il faut connaître un peu l'historique software du projet. Vers le mois d'octobre 2006, alors que je travaillais uniquement sur un produit développé en sous-traitance pour une société de jouet française, on m'a demandé d'amorcer le développement des logiciels pour Tuxdroid. Je suis donc arrivé de mon monde windows (le seul que je connaissais ...) dans un tout nouveau monde inconnu. Ma mission était donc d'offrir une interface de contrôle du robot dans un langage script et de préférence communautaire. Comme tu t'en doute, j'étais vraiment le mieux placé pour remplir cette mission lol. Mon choix c'est porté (peut-être par ignorance) sur python. Comme la société était très pressé de pouvoir proposer qqchose, j'ai du obtenir des résultats en 1 ou 2 mois en devant en même temps apprendre linux, python et le c (Je n'en avais fait qu'à l'école). L'architecture daemon-api tcpip est donc née dans un total amateurisme. La boite comptait ensuite sur la communauté python, pour créer du contenu. Mais, on s'est fourré le doigt dans l'oeil... Alors j'ai du continuer à m'arracher pour créer des couches de plus haut niveau pour pouvoir créer des "gadgets" accessibles à monsieur tout le monde (Gadget manager, etc ...) (Ben oui, faut bien en vendre des tux, sinon on ferme les portes...). Depuis que j'ai démarré le projet, j'ai la tête dans le guidon, et c'est seulement depuis le tout début de cette année, que j'ai enfin pu reprendre tout à la base. J'ai donc pu profiter de l'expérience du premier système et des idées de Jaguarondi (Qui a beaucoup réfléchit sur l'architecture et qui c'est beaucoup entretenu avec des gens ayant un meilleur feeling que moi sur ce genre de développement).
Donc, avec Jaguarondi, on a fait une review des fonctionnalités du daemon.
A l'heure actuelle j'ai pratiquement terminé la première couche, qui offre une bien meilleur abstraction du robot (L'insertion de sons dans la flash est entièrement géré par cette couche maintenant). Cette couche est composée de 2 librairies so pour linux et 2 DLL pour windows (tout est cross-compilable maintenant ...). Une librairie pour le control du robot (tux_driver) et une librairie pour le control de la synthèse vocal (tux_osl). J'ai fait les wrappers pour ces librairies pour c(et c++), python et pascal. En ce qui concerne les commandes, requêtes et status, tout ce passe dans les strings. Ce qui fait que les API communiqueront avec tux uniquement en envoyant des commandes du genre (TUX_CMD:WINGS:ON_DURING:5.0,UP). Et elles recevront les évênements sous la forme ("light_level:float:50.0:3.09") (le 3.09 indique le delay avec le dernier changement d'état, c'est aussi une grande nouveauté) Les requêtes peuvent demander l'état d'un status particulier (même format que les évêments) ou l'état de tout les status d'un seul coup.
J'ai fait un petit serveur web en python pour tester ça, et une page web peut balancer des commandes à Tux sans autre chose que des tags html.
Il y a aussi un parser de macro dans les librairies qui permet d'interpréter par exemple ce fichier text :

0.0:TUX_CMD:MOUTH:OPEN
0.0:OSL_CMD:EFFECT:CRAZY_PITCH:START:100,250,40
0.0:OSL_CMD:TTS:SET_LOCUTOR:Heather8k
0.0:OSL_CMD:TTS:SPEAK:System failure ! The system is completly unstable !
6.0:OSL_CMD:EFFECT:CRAZY_PITCH:STOP
6.0:TUX_CMD:MOUTH:CLOSE

Le macro est envoyé au deux librairies qui prennent uniquement les commandes qui les concernent.

Voila, en gros où on en est du coté soft.
Si je viens te faire ce petit état des lieux, c'est parce que je suis tombé sur ton site il y a quelques jours et que j'ai été impressionné par le fait que tu ai eu le courage de retranscrire ma bordélique API en python lol
Et je me demandais si il ne serait pas intéressant de collaborer un peu, peut-être sur l'interface service-api ou api ou framework, ou autre pour la V2 de l'architecture.
Si tu es intéressé, tu as mon email et j'ai la même adresse sur msn. Quoi qu'il en sois je repasserai sur ton site.

A bientôt,
Rémi

Ulhume, le 8 April, 2008 - 09:21

Et bien sans vouloir te jeter des fleurs, pour un système développé à la volée et dans l'urgence, ce n'est déjà pas mal. Crois-moi, j'ai bossé avec des systèmes dit "industriels" beaucoup plus bordéliques que cela en tout point !

Concernant ton nouveau protocole, je ne suis pas sur de tout comprendre. Arrêtes moi si je me trompe mais tu dis donc que le serveur TCP/IP "raw" de la v1.0 est remplacé par un serveur HTTP, c'est cela ? Si tel est le cas, je ne comprends pas bien ton formatage de chaînes qui ne semble pas suivre une formalisation type XML. Pourquoi construis-tu pas des requêtes de la forme

  1. <sequence device="tux1">
  2.   <invoke method="tux.mouth.open" />
  3.   <set name="tts.locutor" value="Heather8k"/>
  4.   <invoke method="tts.speak">
  5.     <parameter>System failure ! The system is completly unstable !</parameter>
  6.   </invoke>
  7. </sequence>
  8. <!-- ici une temporisation à la charge de l'API -->
  9. <sequence device="tux1">
  10.   <invoke method="tux.mouth.close" />
  11. </sequence>

L'avantage d'utiliser le XML c'est que tu peux écrire le format de manière rigide (via un xsd) et être ainsi certain de ne jamais dériver et de faire des cas particuliers qui rendront la rédaction d'un API plus délicate.

Sinon cela me parait aller dans le bon sens ta nouvelle approche,si tu recherches sur ce site y'avait eu pas mal d'idée échangées avec Jacorondi sur une manière de restructurer l'API. Il y a peut-être des choses à récupérer.

Sinon, oui je suis intéressé pour collaborer avec toi, sans aucun soucis. Dis moi comment tu vois cela.

Rémi Jocaille, le 8 April, 2008 - 10:15

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 Wink 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

Ulhume, le 8 April, 2008 - 10:34

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 Wink

Poster un nouveau commentaire

Le contenu de ce champ est gardé secret et ne sera pas montré publiquement.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • To highlight piece of code, just surround them with <code type="language"> Your code &tl;/code>>. Language can be java,c++,bash,etc... Everything Geshi support.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Textual smileys will be replaced with graphical ones.
  • Les adresses de pages web et de messagerie électronique sont transformées en liens automatiquement.

Plus d'informations sur les options de formatage