plan B...ou comment parer l'hibernation de nos lapinous.

Un peu de flood pour detendre l'atmosphere

C'est tellement vrai! LOL

Les testeurs sont toujours la ?

Peut-être faut il remonter la liste des volontaires et voir qui est dispo ?

Testeur present

Je suis (toujours prêt) à dev, mais que en PHP, XHTML/CSS, JS.

A propos de la reco vocale : j'ai lu dans SVM (celui de ce mois, ou celui d'avant) que la reco du lapin a été développé par Acapella, un des leaders mondiaux dans ce domaine.

C'est la synthèse qui vient d'Acapella... Pas la reco à ma connaissance...

nabazland a écrit:

C'est la synthèse qui vient d'Acapella... Pas la reco à ma connaissance...

C'est effectivement ce qui semble être indiqué ici : http://www.acapela-group.fr/nabaztag-violet-7-217-text-speech.html

Est-ce que le plan B pourrait fonctionner sur un Windows Home Server ?

Je vais bientot investir dans un petit serveur domestique, donc si je peux aider....

doune74 a écrit:

Est-ce que le plan B pourrait fonctionner sur un Windows Home Server ?

Je vais bientot investir dans un petit serveur domestique, donc si je peux aider....

Alors je ne conseil pas windows

lemulot a écrit:

doune74 a écrit:

Est-ce que le plan B pourrait fonctionner sur un Windows Home Server ?

Je vais bientot investir dans un petit serveur domestique, donc si je peux aider....

Alors je ne conseil pas windows

Pourquoi ? apache et php fonctionnent très bien sur windows. J'utilise des serveurs web à la fois sur windows et linux (principalement autour du langage ruby) et je ne vois pas bien la difference.

Maintenant WHS est une version particulière de windows peut-être il y a t-il une limitation quant à l'utilisation d'un serveur web autre que celui fournit avec l'os.

nabazland a écrit:

C'est la synthèse qui vient d'Acapella... Pas la reco à ma connaissance...

Oups, désolé pour l'erreur !

Et installer PHP sur Windows est quand même beaucoup plus simple que sous Linux ! (Apache je sais pas, par contre j'ai mis PHP sur mon PC sous XP édition familiale pour m'en servir en CLI, y'a pas plus simple !)

Harfangdesneiges a écrit:

Je suis (toujours prêt) à dev, mais que en PHP, XHTML/CSS, JS.

Si tu veux faire du dev sur OpenNab, toutes les bonnes volontés sont les bienvenues.

Il y a un dev PHP/XHTML/CSS/JS qui serait très utile et qui n'implique qu'une connaissance minime de l'existant, c'est l'interface d'administration (qui n'a jamais été développée parce que la partie "visuelle" HTML,CSS et compagnie c'est pas vraiment mon truc).

C'est, approximativement, l'équivalent de my.nabaztag.com , cette interface devrait permettre de
- créer un compte sur le serveur avec nom et mot de passe (ce qui, concrètement, demande seulement de créer un fichier .ini au bon endroit sur le serveur)
- se connecter avec le nom et le mot de passe
- accéder aux multiples fonctionnalités

Cela ne nécessite qu'une connaissance minimale de la machine interne d'OpenNab car le système est fait de telle sorte que toutes les fonctionnalités soient utilisables à travers une API.
Le seul point qui nécessite de modifier le code actuel, c'est que l'API n'est pas protégée par un mot de passe et qu'il faudra y rajouter un contrôle de type digest authentication.

Pour le Dev PHP/HTML(le XHTML est mort l'été dernier avec l'annonce du HTML5! rappelez vous!)/CSS je suis la en ce qui concerne la partie visuel je peut faire un truc mais ça prendra du temps

sinon je relit le code d'openNab en ce moment afin d'être prêt au cas où le 8 octobre (si je me trompe pas l'info sur la reprise ou non tombe ce jour la?)

akkes a écrit:

le XHTML est mort l'été dernier avec l'annonce du HTML5! rappelez vous!

C'est sûr ! Et si on veut faire dans la compatibilité, HTML 5 est meilleur que XHTML envoyé avec le type MIME application/xhtml+xml (IE 6 n'a aucun support XHTML).

Osef d'IE 6 ?

akkes a écrit:

Pour le Dev PHP/HTML(le XHTML est mort l'été dernier avec l'annonce du HTML5! rappelez vous!)/CSS je suis la en ce qui concerne la partie visuel je peut faire un truc mais ça prendra du temps

Vu de chez moi, tout ça c'est du pareil au même
Du moment que c'est accessible sur la plupart des OS...

Une seule réelle contrainte : la modularité. Un des principes fondamentaux d'OpenNab est le système de plugins qui permet d'étendre les fonctionnalités sans toucher au noyau (la liste actuelle des plugins est là). Chaque plugin définit notamment sa propre API.
Idéalement, l'interface utilisateur conserverait ce principe et la partie visuelle propre à chaque plugin devrait se trouver à l'intérieur de celui-ci de telle sorte que chaque rajout de plugin n'implique pas de modif de code dans la partie commune.

akkes a écrit:

sinon je relit le code d'openNab en ce moment afin d'être prêt au cas où le 8 octobre (si je me trompe pas l'info sur la reprise ou non tombe ce jour la?)

Si tu as des questions, n'hésite pas.

Harfangdesneiges a écrit:

nabazland a écrit:

C'est la synthèse qui vient d'Acapella... Pas la reco à ma connaissance...

Oups, désolé pour l'erreur !

Et installer PHP sur Windows est quand même beaucoup plus simple que sous Linux ! (Apache je sais pas, par contre j'ai mis PHP sur mon PC sous XP édition familiale pour m'en servir en CLI, y'a pas plus simple !)

Installer php sous linux, ca se résume en une ligne de commande:

Code:

aptitude install php-cli

Je ne pense pas que ca soit beaucoup plus difficile que sous windows...

Sinon, en dehors de cela, s'il y a des devs php/html qui s'ennuyent, y'a aussi l'interface admin de openjabnab qui aurait besoin d'avancer un peu

Pixel du Rezo a écrit:

Installer php sous linux, ca se résume en une ligne de commande:

Code:

aptitude install php-cli

Si tu compile PHP pour l'utiliser avec Apache sous Linux, c'est long ! Et PHP n'a pas très grand intérêt à être utilisé uniquement en ligne de commande (ton paquet, c'est uniquement PHP en CLI ou c'est autre chose ?)

a vrai dire linux permet d'économiser de la RAM et du proc car on n'est pas obligé d'installer Xorg (interface graphique) par contre si le serveur est sous tux je serait du genre a recommander Archlinuxpour sa légerté

sinon pour les plugins on peut utiliser un include / une iframe (même si je déconseille cette technique) ou faire un système a la wordpress mais cela obligerait a re-coder tout les plugins et je pense pas que ce soit très judicieux.

@oaz t'a pas une version du code plus commenté? et un truc clair sur le langage nab? non parce que ça "7fffffff0103030207010e2802050000000000000b0d00" c'est pas super digeste (/vl/tests/test_ambientblock.php)

EDIT: 2/3 corrections

Akkes (et les autres)

Le décodage des ambientblock est la (parmi tant d'autres choses) : http://www-public.it-sudparis.eu/~leriche/projetud/XMPP-Nabaztag/RapportPFE_Nabaztag.pdf

akkes a écrit:

sinon pour les plugins on peut utiliser un include / une iframe (même si je déconseille cette technique) ou faire un système a la wordpress mais cela obligerait a re-coder tout les plugins et je pense pas que ce soit très judicieux.

la demo de l'API d'OpenNab utilise déjà un système modulaire. Chaque plugin définit un fichier _demo.php qui contient le formulaire correspondant à l'API fournie par le plugin concerné.
En reprenant le principe des /vl/api_demo/index.php et /vl/plugins/*/_demo.php, je pense qu'il y a moyen de faire une interface d'admin complète et modulaire.

akkes a écrit:

@oaz t'a pas une version du code plus commenté? et un truc clair sur le langage nab? non parce que ça "7fffffff0103030207010e2802050000000000000b0d00" c'est pas super digeste (/vl/tests/test_ambientblock.php)

Il faudrait que j'écrive un jour de la 'doc pour développeurs' sur le site web d'OpenNab mais c'est en priorité très basse (pas le temps).
Il y en avait un peu sur wiki nab, il faudrait aussi que je la retrouve.

Si quelqu'un veut enrichir le site web d'OpenNab, il est le bienvenu. Normalement c'est un wiki (un pmwiki) qui devrait être modifiable en ligne moyennant quelques configurations adéquates.

Sinon pour les 'ambient', c'est expliqué là : /vl/plugins/ambient/readme.txt

Merci nag et oaz.

@oaz j'avais idée de faire un page modifiant le .ini permettant d' activer/désactiver les plug et d'utiliser le readme.txt comme description

Cela dit j'ai dernièrement lu ceci => http://www.kwett.fr/projets/openjabnab/openjabnab_c_est_reparti du coup je me demande si cela vaut le coup de développer opennab vu la charge serveur de la demande en boucle de demandes alors qu' openjabnab utilise jabber et nécessite donc une charge en serveur plus moindre.

Ne serait-il pas intéressant que les deux projets collaborent plutôt que de se développer chacun de leurs coté?

ps: j'ai failli agoniser en lisant cela http://www.ohloh.net/p/openjabnab (pour les flemmards openjabnab est présenté comme successeur d'opennab)

akkes a écrit:

Merci nag et oaz.

@oaz j'avais idée de faire un page modifiant le .ini permettant d' activer/désactiver les plug et d'utiliser le readme.txt comme description

C'est effectivement une fonctionnalité qui manque pour qu'un utilisateur puisse profiter de son lapin car c'est un peu l'équivalent de l'activation/desactivation des services de my.nabaztag.com. Cela peut donc être un bon début pour l'interface d'admin dont je parlais un peu plus haut.
2 points à noter :
- sur OpenNab, j'ai une règle implicite qui dit 'pas d'interface utilisateur qui tape directement dans le moteur, toujours passer par une API' (pour avoir des séparations claires entres les diverses parties du soft et pour pouvoir tout piloter par programmation). En l'occurrence, il s'agit juste de rajouter une API de lecture écriture sur la config de chaque utilisateur. Si tu veux te lancer dans la réalisation de cette interface, je peux rapidement te filer un plugin qui rajoute cette API.
- les fichiers readme.txt ne me semblent pas très viables à long terme pour faire une interface utilisateur propre. Ils gagneraient surement à évoluer vers quelque chose de plus structuré (des fichiers XML qui contiennent des morceaux de HTML ?)

akkes a écrit:

Cela dit j'ai dernièrement lu ceci => http://www.kwett.fr/projets/openjabnab/openjabnab_c_est_reparti du coup je me demande si cela vaut le coup de développer opennab vu la charge serveur de la demande en boucle de demandes alors qu' openjabnab utilise jabber et nécessite donc une charge en serveur plus moindre.

Je sais bien que l'avenir est dans le protocole XMPP.

Pour cela, je suis en train de faire une extension à OpenNab pour le transformer en serveur XMPP à peu de frais.
L'idée c'est de
- conserver intégralement un OpenNab serveur HTTP qui implémente toute la logique des applications avec ses plugins
- rajouter un exécutable générique que les lapins voient comme un serveur XMPP mais qui relaie tous les appels au serveur HTTP
- rajouter une commande au niveau du développement des plugins qui permet de signaler au relai XMPP que tel lapin a reçu une commande et qu'il faudrait l'envoyer tout de suite (en pratique le relai XMPP écoute sur un port de controle UDP qui fait office de "ping")

Donc la charge d'un serveur OpenNab due aux pings ne sera bientôt plus un problème.

akkes a écrit:

Ne serait-il pas intéressant que les deux projets collaborent plutôt que de se développer chacun de leurs coté?

ps: j'ai failli agoniser en lisant cela http://www.ohloh.net/p/openjabnab (pour les flemmards openjabnab est présenté comme successeur d'opennab)

Comme je l'ai écrit sur ce forum je ne sais plus où, la collaboration peut venir d'API similaires qui permettent les échanges entre lapins connectés sur l'un ou l'autre.
Une collaboration plus poussée me parait difficile car les choix de technos et d'architecture sont quand même très différents.

Sur la succession d'opennab, il y a une partie de vrai car en tant que 'proxy vers les serveurs officiels', openjabnab est le successeur d'opennab - et il est sûr et certain qu'opennab ne se connectera plus jamais à un serveur officiel quels que soient l'avenir de ceux-ci.

oaz a écrit:

2 points à noter :
- sur OpenNab, j'ai une règle implicite qui dit 'pas d'interface utilisateur qui tape directement dans le moteur, toujours passer par une API' (pour avoir des séparations claires entres les diverses parties du soft et pour pouvoir tout piloter par programmation). En l'occurrence, il s'agit juste de rajouter une API de lecture écriture sur la config de chaque utilisateur. Si tu veux te lancer dans la réalisation de cette interface, je peux rapidement te filer un plugin qui rajoute cette API.

Je veut bien de ton code j'ai déjà commencé a préparer un desing

oaz a écrit:

- les fichiers readme.txt ne me semblent pas très viables à long terme pour faire une interface utilisateur propre. Ils gagneraient surement à évoluer vers quelque chose de plus structuré (des fichiers XML qui contiennent des morceaux de HTML ?)

j'avais justement pensé a un nouveau fichier comme "description.inc" qui contiendrait une description en 2/3 lignes

oaz a écrit:

Je sais bien que l'avenir est dans le protocole XMPP.

Pour cela, je suis en train de faire une extension à OpenNab pour le transformer en serveur XMPP à peu de frais.
L'idée c'est de
- conserver intégralement un OpenNab serveur HTTP qui implémente toute la logique des applications avec ses plugins
- rajouter un exécutable générique que les lapins voient comme un serveur XMPP mais qui relaie tous les appels au serveur HTTP
- rajouter une commande au niveau du développement des plugins qui permet de signaler au relai XMPP que tel lapin a reçu une commande et qu'il faudrait l'envoyer tout de suite (en pratique le relai XMPP écoute sur un port de controle UDP qui fait office de "ping")

Donc la charge d'un serveur OpenNab due aux pings ne sera bientôt plus un problème.

bonne idée! Je n'y avais pas songé.

oaz a écrit:

Comme je l'ai écrit sur ce forum je ne sais plus où, la collaboration peut venir d'API similaires qui permettent les échanges entre lapins connectés sur l'un ou l'autre.
Une collaboration plus poussée me parait difficile car les choix de technos et d'architecture sont quand même très différents.

un site internet qui permette d'inscrire son nabaztag: on peut (dans le cas où violet ferme reprendre l'U.R.L violet.net ou nabaztag.com cette adresse permetrait d'inscrire son nab:z soit sur opennab soit sur openjabnab et le site déciderait exactement duquel (server opennab1 ou server opennab2 si la personne a choisit un serveur opennab)

akkes a écrit:

Ne serait-il pas intéressant que les deux projets collaborent plutôt que de se développer chacun de leurs coté?

l'idée est de ne créer qu'un seul type de serveur mais avec plus de monde c-à-d les 2 projets ainsi que leurs équipes fusionnent ensemble afin qu'il n'y ai qu'un seul projet mais qui se développe plus vite

ps aux admins: je pense que laisser les discutions des devs concernant le projet opennab visibles a tous peut être intéressant, cela permettrait un suivit plus grand du projet par les membres du forum. Le tout avec votre autorisation bien sur

akkes a écrit:

Cela dit j'ai dernièrement lu ceci => http://www.kwett.fr/projets/openjabnab/openjabnab_c_est_reparti du coup je me demande si cela vaut le coup de développer opennab vu la charge serveur de la demande en boucle de demandes alors qu' openjabnab utilise jabber et nécessite donc une charge en serveur plus moindre.

Effectivement, le développement de openJabNab est reparti... et il s'agit de mon site
Je continu d'avancer doucement le développement des plugins afin d'obtenir des services plus ou moins identiques à ceux de Violet et opennab (car openjabnab n'est pas aussi avancé que opennab).
J'envisage de mettre à disposition des testeurs mon serveur d'ici quelques semaines afin de faire des tests avec plusieurs lapins (ca m'evitera de devoir en racheter... car pour l'instant, c'est pas ma priorité au niveau des finances )