Présentation réalisée lors de la rencontre développeur du 4 juillet 2013
L'objectif était de faire une introduction à l'AF est d'ouvrir la discussion.
Pour ceux qui souhaite approfondir, direction le groupe https://decibel.ni.com/content/groups/actor-framework-2011
Super récap de l'actor framework; comme je me pose les même questions que le dernier slide, je suis particulièrement preneur des réponses que vous y avez apporté afin d'aider ma reflexion...
Pas facile de résumé la discussion. Pour le faire en 2 mots : ça semble être un framework puissant, mais avec une mise en oeuvre délicate et une "présentation" très inhabituelle.
Question est-ce que le jeu en vos la chandelle lorsque l'on sait se débrouiller sans ?
Pour ma part, je devrais pourvoir enfin le tester en grandeur nature et je pense qu cela peut apporter beaucoup, notamment pour éviter l'utilisation de classes référencées qui peuvent apporter de petits soucis "colatéraux".
Olivier
Un des problèmes est que c'est massivement orienté objet (acteurs et messages sont des classes). Dans l'absolu ça me va, mais si LabVIEW est OOP, l'utilisation n'est ni aisée ni fluide. Cela créée beaucoup de VIs qui ne font rien de fonctionnel (boilerplate), et même s'ils sont créés automatiquement ça vient encombrer le code source.
Pour un nouveau projet, je serais partant, mais mon problème se pose pour une application existante dont j'ai besoin d'étendre l'architecture. S'il y avait déjà un framework de messaging, autant rester avec.
Dans mon cas le messaging est basique (chaque contrôleur reçoit des commandes en QMH, qui lui-même a soit du DVR pour instancier les objets de comm hardware, soit pas de DVR mais l'objet de comm hardware met ses data en queue). C'est là que le choix est difficile, le passage à de l'AOP s'apparentant presque à une réécriture. Mais comme je dois remanier pas mal de choses de toutes façons, ça me titille...
Là où j'ai du mal à me représenter la chose, c'est quand une action dépend d'un acteur qui est en train de faire le job, et que tu dois attendre sa réponse, sachant que AristosQueue (le concepteur du framework) dit que tu dois oublier le messaging synchrone (envoie commande, attente réponse). L'asynchronicité me trouble
Je m'interroge aussi sur la mise en application de l'AF.
Concrètement, j'ai réalisé une architecture GOOP pour un projet avec des Objets dont le comportement était de fait asynchrones. Ce projet traite de la gestion de trames arrivant sur le port réseau UDP afin de suivre l'activité et le status de différents instruments déportés.
Au bénéfice de congés bien mérités, j'ai pris temps de me documenter sur l'AF afin d'identifier s'il pouvait contribuer efficacement à ce projet, le moment était propice puisqu'aucune implémentation n'était réalisée.
Conclusion, même si le moment et le sujet s'y prétait fortement, j'ai jugé que les points suivants pourraient nuire à une implémentation s'appuyant sur l'AF.
Je souhaite bon courage à tous ceux qui feront le premier pas. L'AF me séduit profondemment, j'aurais un grand plaisir à l'implémenter... mais pas dans l'immédiat.
salut, @Behr-33, je partage tes retours sur l'AF, surtout ".../... L'AF doit être connu de l'ensemble de l'équipe de développement. Mon équipe ne satisfait pas ce critère. L'AF nécessite une forte expertise en LabVIEW. .../...
Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion
MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group