Participants : JP Gelas, L. Médini, M. Mrissa
Excusé : JP Jamont
* JPJ : à faire…
Choix d'architecture : le moteur d'adaptation peut être centralisé (une instance pour tous les couples avatar ; objet)) ; dans ce cas, l'architecture est de type ESB. À l'inverse, une instance de moteur peut être définie pour chaque couple : plus proche du P2P. De façon à avoir une architecture plus flexible, on s'orienterait plutôt vers la seconde alternative.
Cette solution permettrait de “distribuer” le moteur d'adaptation avec un traitement local des règles concernant les données recueillies par l'objet et un envoi des résultats de ces traitements à l'avatar pour ne faire circuler entre l'objet et l'avatar que les informations intéressantes au regard de la situation courante.
Il faut donc définir un moyen de transmettre les règles, les connaissances d'adaptation, [éventuellement le code de traitement de ces connaissances,] les commandes de [négociation et de] changement de protocole, et l'“acknowledgement”. Au final, il s'agit donc de déterminer un protocole d'échange de connaissances d'adaptation et de contrôle du protocole de communication entre avatar et objet.