continuum

User Tools

Site Tools

Trace:
compte_rendu_29_novembre_2010

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
compte_rendu_29_novembre_2010 [2010/11/29 09:53] – tiglicompte_rendu_29_novembre_2010 [2011/09/29 09:15] (current) – lavirott
Line 9: Line 9:
 === Ordre du jour  ===  === Ordre du jour  === 
  
-== Présentation  Anoto  par Emeric== +== Présentation  Anoto  par Emeric == 
  
 [[http://www.anoto.com/| Site Anoto]] [[http://www.anoto.com/| Site Anoto]]
Line 43: Line 43:
 et sur les services. et sur les services.
 Annotation en pseudo langage.  Annotation en pseudo langage. 
 +
 +Pas d'AA dans les meta-données des Services et Devices.
 +
  
 == Conséquence sur les AAs ==  == Conséquence sur les AAs == 
Line 59: Line 62:
  
  
 +== Présentation de Vincent sur l'évaluation des performances et nouvelle grammaires des AAs == 
 +
 +{{:reunions:continuum_grenoble_wcomp-2.4-1-1.pdf|Présentation}}
 +
 +TODO ::: envoyer la grammaire des AAs à IIHM
 +
 +
 +== Travail sur le scenario du fontainier pour la projection des phrases en langage pseudo naturel vers des AAs == 
 +
 +Cas 1 : si (vitesse > x et milieu encombré) alors disable (S1 et S2) 
 +
 +Dans ce cas la condition correspond vraiment à un changement de contexte et la désactivation des AAs 
 +qui utilisent S1 et S2 
 +
 +
 +Idée : Cas généraux (deux cas) :
 +
 +condition contexte -> liste d'AA à activer / désactiver 
 +
 +AA : condition -> action 
 +
 +
 +Cas 2 : Me localiser sur la carte / Où suis-je
 +
 +Comment traduire en AA
 +
 +Cas 3 :  Problème du rétroappel ...
 +En fait il faut aussi annoter les méthodes+getter (ou rétro appel) qui "vont bien" comme méthode possible 
 +pour le device. 
 +
 +Vu le nombre de getter, il faut donc le faire à la main ... 
 +
 +exemple : checkbox pour piloter une light => l'utilisation de checkbox.setchange__getvalue
 +pour une methode setchange()
 +
 +Cas 4 : problème de l'initialisation (pas d'initialisation avec WComp avant l'émission d'events) 
 +
 +Cas 5 : si le casque est baissé afficher la position des points d'intérêt dans le casque
 +
 +Condition (si le casque est baissé) 
 +Action : afficher les points d'intérêt dans le casque
 +
 +
 +Cas 6 : je veux regarder l'état de ma machine à laver 
 +  * sous tension (On/Off) [boolean]
 +  * cycle [enum]
 +  * programme  [enum]
 +  * temperature [entier]
 +  * temps restant (heure de terminaison) [0..60]
 +
 +== Cinq problèmes : ==
 +
 +- alignement des terminologies (afficher, montrer)  
 +
 +- introduction des composants intermédiaires (insertion de composants intermédiaires : recasteur, ...) 
 +
 +- gestion des signatures (par retroappel, ...)
 +
 +- deux niveaux de gestion des condition "circonstancielles" (compléments circonstanciels) : niveau contexte 
 +ou membre gauche (trigger d'action dans un AA) 
 +
 +- Problème de cohérence entre les états des composants à l'initialisation (exemple plusieurs checkbox qui
 +attaque un light, si la checkbox est on et la light off, non seulement l'initialisation aujourd'hui ne gère pas la cohérence, mais en plus on ne sait pas si l'état initial doit être On/On ou Off/Off)
 +
 +
 +1>  Alignement :
 +
 +Step 1 
 +Emric fonctionne avec une grammaire et des terminaux "types" : exemple 
 +Audiosource , AudioSink dont il connait les méthodes types :
 +
 +Audiosource.setaudio
 +
 +Audiosink.getaudio 
 +
 +grâce à un "terminal" comme écouter (mots clef action).
 +
 +Step 2 
 +Ensuite il fait une requête dans la BdC sur AudioSink.setaudio 
 +et AudioSource.getaudio pour récupérer les devices avec les méthodes ou events équivalents 
 +
 +Step 3 
 +Les metadonnées d'un devices devant fournir à la BdC les équivalences de ses méthodes et 
 +events en terme de méthodes et events "types" pour préparer ces requêtes et les composants intermédiaires 
 +nécessaires à ces équivalences
 +
 +Attention : 
 +
 +- il faut que la BdC renvoie quand même un nom de "famille" de devices telle GPS* ou par convention 
 +la BdC part du principe que tous les devices GPS* (ex. GPS1, GPS2) ont la même interface. Autre exemple, des pointcuts qui sont des "ou" entre les devices possibles exemple Localisateur | GPS.
 +
 +ou
 +
 +- la partie pointcut matching fait appel à la BdC
 +
 +2> composants intermédiaires à rajouter  pour  rendre équivalentes des méthodes AudioSource.getaudio
 +avec des méthodes concrètes du service
 +
 +
 +3> retroappel : idem que 2> mais avec le retroappel
 +
 +
 +4> gérer par redondance, si possible (ex. du disable)
 +
 +
 +
 +== TODOs == 
 +
 +Sur la base  du scenario du fontainier recherche de vanne + PDA / Casque
 +
 +
 +Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.
 +
 +IIHM : Reprendre la grammaire du langage pseudo-naturel, définir le vocabulaire de base pour les actions 
 +et des noms terminaux de manière plus générale (type de device et méthodes et events) 
 +
 +Hadas : Spécifier les métadonnées dans les services et services pour dispositifs.
 +
 +
 +Vers le second démonstrateur pour février .
 +
 +== Prochaine Réunion ==
  
  
 +VideoConf le 14/01/11 à 14h
compte_rendu_29_novembre_2010.1291024420.txt.gz · Last modified: 2010/11/29 09:53 by tigli