Rajouter une fonction jv_data/jv_extra

[ghost]

Bonjour,

Serait-il possible de rajouter la fonction suivante dans le fichier utils.sh:

# Public: Displays a data
# $1 - message to display
jv_data() { jv_message "$1" "data" "data:" ;}

"$1" = le message "data" = pour la web api "data:" = pour mon serveur socket, car le mot clef $data apparais dans le chat et me permettrais de traiter le message.

ou alors:

jv_message() {
    if $jv_json; then
        jv_print_json "$2" "$1"
    else
        echo -e "$3$2:$1$_reset"
    fi
}

# Public: Displays a data
# $1 - message to display
jv_data() { jv_message "$1" "data" "" ;}

Même fonction, mais sans le "data:" final. Et modification de jv_message pour rajouter $2. Cela ne changera rien pour la webapi, mais juste l'affichage des warning/debug en affichage dans la console qui serait préfixé.

Cela suffirait à remplir la demande du ticket #786 et me permettrais de récupérer des données envoyées d'autres plugins à travers mon serveur socket.

Par exemple, j'ai repris le plugin "montre-moi", en l'adaptant. SANS cette fonction, je reçois un message simple awnser:"{img:url}". Je peux le t,raiter, mais cela n'ait pas propre. AVEC cette fonction, je reçois {data : {"img": url }}

De plus, je pense que cela pourrait être bénéfique pour votre web api. Elle permettrait un ajout d'informations supplémentaires pour les personnes qui l'appellent.

Cordialement

[alexylem]

J'ai revu le PR et il y a un truc qui me gène sur le principe. Je comprends l'objectif mais j'ai l'impression que les informations véhiculées via jv_data seront utilisées de manière arbitraire et non générique. Je m'explique: Dans l'exemple donné ici #786 les tags météo seront "hardcodés" par un système externe qui devra savoir à l'avance comment ils sont nommés. Dans l'exemple de ce ticket, l'adaptation du plugin "montre-moi" devra hardcoder la structure attendue ("img"...). l'API de Jarvis est aujourd'hui complètement générique (liste d'answer, complémentée de "error", "warning", "debug", "log"). Chacune de ces entrées est une ligne de texte. En ajoutant "data" on affiche un format non prédéfini (du JSON, de l'HTML, ...) difficile à exploiter, car uniquement lorsque l'auteur du plugin envoyant data et l'auteur du plugin l'interprétant se sont mis d'accord au préalable. Voila j'espère que je suis clair... Et si on partait la dessus, il faudrait aussi modifier le plugin jarvis-ui et autres (android app...) pour interpréter (cacher, ou couleur spécifique) ce nouveau type de message. Ca serait peut-être plus simple d'utiliser un message existant si on est sur un cas à la marge, genre jv_debug ou jv_info.

[ghost]

Je m'excuse des éventuelles fautes d'orthographe. Je précise que les codes des plugins ont été mis en ligne, mais ne sont pas 100% fonctionnels en dehors de mon environnement de développement.

Le problème que j'ai actuellement est que le serveur socket écoute toute les sorties console et ne peut les différentier uniquement par le préfixe. Hors les fonctions jv_debug ou jv_info non pas de préfix en console. De plus, je ne peux pas utiliser le -j sinon tout le dynamisme du socket est caduque. En effet, le -j retourne la réponse une fois le plugin ayant fini complètement sont exécution.

Les plug-ins actuels ne pourraient certes pas exploiter le nouveau jv_data dans l'immédiat. Mais les créateurs d'application pourraient fournir une entrée pour les autres plug-ins.

Par exemple : l'interface web intégrerait des fichiers js fais par les créateurs des plugins. Le fichier js serais ajouté au moment de l'installation du nouveau plugin. Voici les dépôts: Le serveur socket: https://github.com/kaliones/jarvis-socket Celui-ci appelle automatiquement les fonctions init() des fichiers js dans le dossier plugin.

L'interface web: https://github.com/kaliones/jarvis-ui-socket De même, l'interface appel une fonction dans le fichier js rajouté par le créateur du plugin lors de l'installation. Cela est possible grâce au nom "plugin" qui correspond à l'objet qui porte le nom du fichier et à "fonction" qui correspond a la fonction de l'objet à appeler.

Le plugin montre-moi-socket: https://github.com/kaliones/jarvis-montre-moi-socket Ce plugin utilise jv_data avec un nom et une fonction à lancer.

Cela permet donc au créateur du plugin de traiter lui-même ce qui apparaitra dans l'interface web.

Je conçois que cela veut dire qu'un créateur de plugin devra développer l'intégration dans les plugins tiers. Mais comme pour l'interface qui implémente un objet js. Cela pourrait en être de même, avec un modèle de class java fourni par le développeur de l'application Android. Le créateur du nouveau plugin devras alors développer selon le model fournit pour l'intégrer à l'application.

Si tu as le temps passe voir les différents dépôts, j'ai essayé de faire des readme rapide. Je t'ai envoyé l’accès à mon interface web par mail.

Si tu as une idée de modification pour implémenter un système plus générique, je suis ouvert à toute suggestion.

[ghost]

Apres concernant l'utilisation de jv_info, je veux bien mais il me manque des informations avec le serveur de socket. Il fraudais rajouter un préfixe en mode console soit par une nouvelle option type "-j" pour le json mais avec par exemple la lettre "-o" pour "output" qui ferais la même chose que la console mais avec les préfixes en plus.

 echo -e "$3$2:$1$_reset"

Effectivement dans votre ui je jv_data ouvrirais une notification:

my.error ('unknown key: '+key)

Mais le problème resterais le même avec des données non "génériques" passé dans la fonction jv_info

[lakadev]

Bonsoir,

Comme les 'data' ne sont pas faites pour être lues par l'utilisateur, il n'est pas étonnant que passer par jv_message pose des soucis.

Il y a peut-être une piste à explorer. Ca n'est pas forcément la plus propre ni la plus simple, mais elle serait plus 'rétro-compatible'...

Il s'agirait de définir un nouveau 'hook' commun qui pourrait s'appeller par exemple 'data_push'

Les plugins producteurs appellent le hook 'data_push' avec les données en json. Les plugins consomateurs implementent le hook data_push.

Dans le cas des sockets par exemple :

1) Le plugin montre-moi-socket recherche une image puis appel le hook... jv_hook "data_push" "{ img : 'http://www.exemple.com/exemple.png' }"

2) Le plugin jarvis-socket dans son hook data_push interprête le message et le transmet sans passer par un echo. (en passant par un socket spécial par exemple.)

Il faut voir au niveau performances si c'est satisfaisant.