Attend, c'est un peu restreint ce que tu décris là, c'est qu'un cas particulier d'une conversation chiffrée/authentifiée.
Ça dépend de ce qui t'importe.
Par exemple je peux très bien commencer à discuter avec une personne sur le net, et ensuite vouloir m'assurer que ce soit toujours la même personne, mais à aucun moment je n'ai besoin de savoir qu'il est dans le monde physique !
Je veux pouvoir m'assurer que seul lui ne lise ce que je lui écrit, et ainsi de suite.
Je ne vois pas d'où vient le besoin absolu d'authentifier la personne. Vis-à-vis de quoi d'ailleurs ? de sa carte d'identité ? de son physique ? la couleur de sa peau ?
Tu vois ce que je veux dire ? Il te faut bien un critère dont tu as besoin pour vérifier cette authentification ! Peut-être que pour moi, le seul critère qui suffise c'est "on a rushé tout les deux en B1 à counter-strike la veille" ou "il m'a donné des informations secrète de je ne sais quelle administration", etc…
Je pense que d'une façon générale, le cas d'utilisation que tu décris n'est pas celui visé par ce genre d'outils.
Déjà je ne suis pas sûr que ce soit solvable sans une autorité centrale (ou une chaîne d'autorités en qui tu as confiance) : enfin bon, tu dois mettre ta confiance dans quelqu'un(s).
Sinon, je dirais qu'on est plutôt dans des cas où tu n'as pas forcement besoin de savoir qui est la personne dans le monde physique, tout ce que tu veux c'est être sûr que tu t'adresses à chaque fois à la même personne.
En gros tu as les avantages d'une approche centralisée style jabber où le serveur te garantie que c'est bien la même personne derrière une adresse, mais en décentralisé.
Il ne le fait pas avec une BMW simplement parce que ce qui le retient, ce n'est pas sa conscience, mais le regard des autres (à court et à long terme).
C'est pour ça qu'il ne considère pas ces situations comme comparable, l'une est légale, l'autre non, il s'appuie sur la bienséance selon la société (le regard des autres) et non sa conscience.
Parce que l'outil te permet de « traîner » avec tes contacts, une fois un « hangout » créé, tu peux y retourner, et ce qu'il s'y raconte est sauvegardé, comme un lieu qui existe en dehors de ton ordinateur.
Plus précisément, si j'ai bien compris (et testé avec un compte gmail et un compte autre part jabber), il n'y a que les utilisateurs qui sont passés à Hangout qui ne peuvent plus communiquer avec l'extérieur.
[edit: bon, effectivement c'est que le client qui ignore]
Et il me semble que c'est un passage irréversible, donc dès que tout le monde est passé à Hangout, yapurien!
[edit: tu peux revenir à l'ancien client dans gmail en fait]
Le pire, c'est que tu vois tes contacts qui sont sur Hangout comme connectés (si tu les avais ajouté avant j'imagine), mais si tu envoies un message, ils ne le reçoivent pas !
C'est complètement pervers :)
[edit: non rien, c'est complètement pervers :)]
Je suis globalement d'accord avec toi, pour le pair-à-pair, l'idée était surtout de se débarrasser d'une entité dont les intérêts ne sont peut-être pas les miens, et puis il y a aussi l'idée plutôt utopique de suppression d'un contrôle central, et surtout d'un point central de défaillance (genre vous vous rappelez de megaupload ? ;)
C'est comme quand on découvre l'administration sous linux, il arrive souvent un point où on monte son serveur mail perso, et quand on est plusieurs à faire ça, l'idée de chacun servir de backup mx pour les autres émerge tout naturellement : c'est un peu aussi dans ce même esprit que ma question apparaît (et bon, on en revient, et on fini sur google apps :)
Et ce qu'il manque à un outil comme ça, c'est la possibilité de mettre en place un réseau de confiance pour sauvegarder ses trucs chez les autres sans pour autant qu'ils puissent voir le contenu…
Donc ce n'est pas du tout la même chose, je ne me situe pas au niveau de "l'architecture interne" des agents (genre ton automate permet de décrire comment ça marche dedans), mais je me situe à l'extérieur, au niveau de l'interaction, et mon objectif est de permettre d'avoir des moyens d'interaction, mais aussi des mécanismes d'exécution (scheduling, connections au reste du monde, connexion à l'environnement) qui soient tous le plus proche du problème.
Au final, on est plus dans la fabrication de framework/plateforme SMA, que dans la fabrication de SMA directement (mais comme l'idée sur laquelle je m'appuie est qu'il n'est pas possible d'échapper à la fabrication de ce framework quand on fabrique des SMA, alors ça aide au dev des SMA).
En français j'ai bien un article de journal, je peux te l'envoyer par mail (pas le droit de le diffuser publiquement…), envoie moi un message, ça me ferait plaisir d'être lu, même partiellement :]
Mon argument, c'est que si tu utilises un truc comme le tiens, tu es obligé de traduire ta solution à ton problème dans le "langage" de tes concepts, un peu comme quand on fait de l'objet, on traduit toute interaction en éléments du système sous forme de méthode.
Comme c'est un peu limitant en terme d'abstraction, la communauté du dev (industrielle et académique) a fait des design pattern, des frameworks, qui permettent de palier ces limitations, et ça marche bien.
Mais dans les SMAs, enfin en tout cas dans ceux que j'étudie, on a une conception tellement proche du problème et tellement éloignée de l'implémentation, que ces "contraintes", ces limitations sont trop importantes, on a besoin pour implémenter son SMA d'abstraction ultra adaptées au problème (genre on veut pouvoir raconter dans son implem que notre agent envoie des messages, mais perçoit ses voisins, ce voisinage étant maintenu par l'environnement car il est dynamique et représente l'extérieur du système qu'on ne contrôle pas, qu'il y a des échanges en local mais aussi à distance, qu'ils ne doivent pas être gérés de la même façon par l'agent, etc, et d'autres trucs comme ça).
Et donc, mon truc permet de fabriquer ces abstractions adaptées au problème, ou plus précisément d'en réutiliser pour les composer et faire sa plateforme SMA maison.
C'est là qu'on fait le lien avec les ES, au final, ça semble permettre de définir et de réutiliser des systèmes entre différents jeux, pour les composer dans les entités et définir leur structure et leur dynamique de façon très adaptée et très proche du problème que l'on veut modéliser.
Et on peut mettre dans ces systèmes l'implémentation de ces différentes préoccupations de façon bien séparée.
Forcement, tout les gens qui bossent sur le jeux retrouvent leur billes sans aucun "gap" entre ce qu'ils ont dans la tête (des tanks qui se déplacent, qui ont une tourelle) et la façon dont c'est organisé dans l'implémentation (l'entité tank et tout les composants qui la concernent, et les systèmes qui l'intègrent au reste du monde).
En objet, chacun de ces concepts se seraient retrouvés un peu partout dans différentes parties du code il me semble.
Oui, là la récursivité est un peu différente, c'est pas simplement un truc dans un truc, mais c'est un truc pour fabriquer un autre truc…
Bon, je sais pas, je crois que c'est juste différent, mais je suis très content de voir que mon approche ressemble à un paradigme qui est utilisé sérieusement dans l'industrie, ça veut dire que mon travail n'est pas complètement loufoque :)
Je dis ça parce qu'il est utilisable (et utilisé en pratique), mais il y a quand même beaucoup d'idées qui en font un truc élégant et beau théoriquement, mais qui en pratique est juste lourdingue à utiliser pour le moment (en particulier cette récursivité qui apporte la réutilisation et la composition des différents « aspects » (i.e. les systèmes des ES).
Je pense que j'y réfléchirais plus précisément pour en faire une analyse comparée dans le futur !
Je ne suis pas sûr que ce soit vraiment comparable en terme d'abstractions : d'un côté on a des entités, des systèmes et des composants, de l'autre, on a des écosystèmes et des espèces qui ne peuvent exister qu'au sein d'un écosystème.
Mais si on triche un peu et qu'on fait un parallèle, alors un ES récursif serait un ES dont certaines des entités et/ou des systèmes sont eux-même définis par un ES, et que le lien entre le contenant et l'ES contenu soit cohérent avec les ES.
Tu vois l'idée ? Je ne suis pas sûr que ce soit applicable aux ES en fait…
Dans mon approche, en fait sans cette récursivité, ça sert à rien, on peut rien faire, un peu comme si on avait de la prog orienté composant mais sans composant composites : ce serait chiant :)
Je pense que non, car mon approche ne permet pas d'implémenter des agents, mais l'architecture nécessaire à l'implémentation d'un agent :)
En gros, ça permet, par composition, de choisir quels mécanismes lient l'agent à son environnement.
Un peu comme les systèmes « lient » les entités entre elles et dans leur environnements selon plusieurs aspects.
Une façon simple de voir si c'est comparable ou non, c'est de répondre à cette question : comment tes agents interagissent entre eux et avec leur environnement ?
C'est vrai, mais ça vient surtout, à mon avis, du fait que les outils de debug qu'on a actuellement on été fait pour autre chose que ce paradigme de programmation !
j'irais jusqu'à dire qu'avec des outils de debug ES sur du code ES, ce sera mille fois mieux que du debug OO sur du code OO :)
Il y a donc encore du boulot : l'argument de ton pote est valide dans une vision court terme !
C'est « marrant », j'ai passé 4 ans de ma vie à faire une thèse sur l'aide au développement des systèmes multi-agents (SMA).
Un SMA : un truc avec pleins d'entités qui interagissent entre elles et qui sont régis par leur environnement sur certains aspects.
Ça vous fait penser à quelque chose ?
Les gens qui bossent sur les SMAs s'en foutent un peu de savoir comment ils sont implémentés, mais c'est ce à quoi je me suis intéressé.
Et la solution à laquelle je suis arrivée ressemble TRÈS fortement à l'architecture ES que tu viens de nous présenter.
Je parles bien de l'architecture de l’implémentation d'un SMA, et non pas de l'architecture des SMA eux-même : de la même façon qu'un jeu a une architecture différente selon les types d'entités représentées,leur comportement, leur capacités ; tout les jeux peuvent être implémentés en utilisant une architecture ES.
Ça prend la forme d'une grosse thèse, et puis d'une implem sous forme d'un langage de description d'architectures implémentables en Java.
Le modèle est plus « simple » qu'un ES, il est composé d'espèces et d'écosystème (le parallèle « serait » entité et système), il est récursif (des ES composés d'ES en quelque sorte) et s'appuie sur une brique de base qui est un peu plus riche qu'un composant logiciel (l'écosystème).
Le composant n'est qu'une version simplifié d'un écosystème au final.
C'est pas pareil, mais ça y ressemble quand même beaucoup et c'est pas étonnant, vu que les jeux vidéos ont des organisations qui sont très proches de celles des SMAs !
[^] # Re: Certification
Posté par Victor . En réponse au journal Bitmessage : envoi de messages chiffrés en p2p. Évalué à 2.
Attend, c'est un peu restreint ce que tu décris là, c'est qu'un cas particulier d'une conversation chiffrée/authentifiée.
Ça dépend de ce qui t'importe.
Par exemple je peux très bien commencer à discuter avec une personne sur le net, et ensuite vouloir m'assurer que ce soit toujours la même personne, mais à aucun moment je n'ai besoin de savoir qu'il est dans le monde physique !
Je veux pouvoir m'assurer que seul lui ne lise ce que je lui écrit, et ainsi de suite.
Je ne vois pas d'où vient le besoin absolu d'authentifier la personne. Vis-à-vis de quoi d'ailleurs ? de sa carte d'identité ? de son physique ? la couleur de sa peau ?
Tu vois ce que je veux dire ? Il te faut bien un critère dont tu as besoin pour vérifier cette authentification ! Peut-être que pour moi, le seul critère qui suffise c'est "on a rushé tout les deux en B1 à counter-strike la veille" ou "il m'a donné des informations secrète de je ne sais quelle administration", etc…
[^] # Re: Certification
Posté par Victor . En réponse au journal Bitmessage : envoi de messages chiffrés en p2p. Évalué à 4.
Je pense que d'une façon générale, le cas d'utilisation que tu décris n'est pas celui visé par ce genre d'outils.
Déjà je ne suis pas sûr que ce soit solvable sans une autorité centrale (ou une chaîne d'autorités en qui tu as confiance) : enfin bon, tu dois mettre ta confiance dans quelqu'un(s).
Sinon, je dirais qu'on est plutôt dans des cas où tu n'as pas forcement besoin de savoir qui est la personne dans le monde physique, tout ce que tu veux c'est être sûr que tu t'adresses à chaque fois à la même personne.
En gros tu as les avantages d'une approche centralisée style jabber où le serveur te garantie que c'est bien la même personne derrière une adresse, mais en décentralisé.
[^] # Re: Je doute que ce soit légal au niveau de la loi...
Posté par Victor . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 1.
J'allais voter pertinent, mais j'ai voté inutile à cause de ton PS : ce que c'est agaçant les gens qui se victimisent.
Désolé, en plus c'est complètement stupide de ma part, parce qu'il est pertinent ton commentaire :D
[^] # Re:C'estlégal
Posté par Victor . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 5.
Il ne le fait pas avec une BMW simplement parce que ce qui le retient, ce n'est pas sa conscience, mais le regard des autres (à court et à long terme).
C'est pour ça qu'il ne considère pas ces situations comme comparable, l'une est légale, l'autre non, il s'appuie sur la bienséance selon la société (le regard des autres) et non sa conscience.
Je dis "il", mais je pense "nous" (moi :)
[^] # Re: Hangout
Posté par Victor . En réponse à la dépêche Google Hangouts remplace Talk : la fin de la fédération XMPP ?. Évalué à 2.
D'ailleurs : https://plus.google.com/+RobertPitt/posts/cTLKd1i4vQF
[^] # Re: Hangout
Posté par Victor . En réponse à la dépêche Google Hangouts remplace Talk : la fin de la fédération XMPP ?. Évalué à 4.
Parce que l'outil te permet de « traîner » avec tes contacts, une fois un « hangout » créé, tu peux y retourner, et ce qu'il s'y raconte est sauvegardé, comme un lieu qui existe en dehors de ton ordinateur.
Un chan quoi :)
[^] # Re: Sources ?
Posté par Victor . En réponse à la dépêche Google Hangouts remplace Talk : la fin de la fédération XMPP ?. Évalué à 2. Dernière modification le 22 mai 2013 à 15:14.
Plus précisément, si j'ai bien compris (et testé avec un compte gmail et un compte autre part jabber), il n'y a que les utilisateurs qui sont passés à Hangout qui ne peuvent plus communiquer avec l'extérieur.
[edit: bon, effectivement c'est que le client qui ignore]
Et il me semble que c'est un passage irréversible, donc dès que tout le monde est passé à Hangout, yapurien!
[edit: tu peux revenir à l'ancien client dans gmail en fait]
Le pire, c'est que tu vois tes contacts qui sont sur Hangout comme connectés (si tu les avais ajouté avant j'imagine), mais si tu envoies un message, ils ne le reçoivent pas !
C'est complètement pervers :)
[edit: non rien, c'est complètement pervers :)]
[^] # Re: Mwai
Posté par Victor . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 4.
De ce que j'ai lu/vu (http://www.theverge.com/2013/5/15/4318830/inside-hangouts-googles-big-fix-for-its-messaging-mess), ils abandonnent XMPP, pour le moment GTalk est toujours là, donc, ça marche, mais dès qu'ils virent GTalk c'est fini epistoo, ya pas de doutes pour moi !
[^] # Re: vous oubliez juste ...
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 2.
Franchement, c'est difficile de contre-argumenter sur son témoignage : btsync correspond parfaitement bien au besoin.
Pas de serveurs, de configuration ou je ne sais quoi à mettre en place, et les trucs qu'il partage ne sont pas versionnés.
[^] # Re: Ce qu'il manque
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 3.
Je suis globalement d'accord avec toi, pour le pair-à-pair, l'idée était surtout de se débarrasser d'une entité dont les intérêts ne sont peut-être pas les miens, et puis il y a aussi l'idée plutôt utopique de suppression d'un contrôle central, et surtout d'un point central de défaillance (genre vous vous rappelez de megaupload ? ;)
C'est comme quand on découvre l'administration sous linux, il arrive souvent un point où on monte son serveur mail perso, et quand on est plusieurs à faire ça, l'idée de chacun servir de backup mx pour les autres émerge tout naturellement : c'est un peu aussi dans ce même esprit que ma question apparaît (et bon, on en revient, et on fini sur google apps :)
[^] # Re: Protocole
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 2.
:P ça nous aura au moins permis de découvrir ce truc
[^] # Re: Protocole
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 3.
Tu réponds à quoi ?
C'est une autre app avec un modèle différent (il y a un serveur, qui est closed source !), non ?
# Ce qu'il manque
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 5.
Et ce qu'il manque à un outil comme ça, c'est la possibilité de mettre en place un réseau de confiance pour sauvegarder ses trucs chez les autres sans pour autant qu'ils puissent voir le contenu…
Un espèce de tarsnap (https://www.tarsnap.com/) distribué…
# Protocole
Posté par Victor . En réponse au journal Le test du samedi : Bittorrent Sync, dropbox killer ?. Évalué à 2.
Je me demande si ça ne suffit pas d'avoir le protocole pour en faire une implémentation open source / libre / maison.
J'ai regardé un peu sur le net, c'est clair qu'ils ne planifient pas de rendre l'appli open source (http://forum.bittorrent.com/topic/17782-bittorrent-sync-unofficial-faq/) mais je n'ai rien trouvé sur le proto…
[^] # Re: Avec IPTABLES c'est plus simple et sûr !
Posté par Victor . En réponse au journal youfree enfin un bon tube. Évalué à 3.
Et ça marche vraiment/toujours ce truc ?
On en parlait à un moment, j'avais testé vite fait et j'avais pas eu l'impression que ça marche…
[^] # Re: AccelMethod
Posté par Victor . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 2.
Bah il a l'air de le charger, mais j'ai testé au cas où et ça ne marche pas non plus…
[^] # Re: AccelMethod
Posté par Victor . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 2.
Ouais, pareil pour moi, X ne se lance pas, et les logs n'indiquent aucune erreur, ça se pause juste…
# Sans xorg.conf…
Posté par Victor . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 2.
Cool,
Mais si on a pas de Xorg.conf pour configurer sa carte, on fait comment ?
Il y a peut-être un moyen de le mettre dans le xorg.conf.d ? Sous quel forme ?
Si quelqu'un sait :)
[^] # Re: Différent ?
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 3.
Oui, mais de la même façon que la machine de turing englobe l'objet : c'est pas très pratique :)
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Donc ce n'est pas du tout la même chose, je ne me situe pas au niveau de "l'architecture interne" des agents (genre ton automate permet de décrire comment ça marche dedans), mais je me situe à l'extérieur, au niveau de l'interaction, et mon objectif est de permettre d'avoir des moyens d'interaction, mais aussi des mécanismes d'exécution (scheduling, connections au reste du monde, connexion à l'environnement) qui soient tous le plus proche du problème.
Au final, on est plus dans la fabrication de framework/plateforme SMA, que dans la fabrication de SMA directement (mais comme l'idée sur laquelle je m'appuie est qu'il n'est pas possible d'échapper à la fabrication de ce framework quand on fabrique des SMA, alors ça aide au dev des SMA).
En français j'ai bien un article de journal, je peux te l'envoyer par mail (pas le droit de le diffuser publiquement…), envoie moi un message, ça me ferait plaisir d'être lu, même partiellement :]
Mon argument, c'est que si tu utilises un truc comme le tiens, tu es obligé de traduire ta solution à ton problème dans le "langage" de tes concepts, un peu comme quand on fait de l'objet, on traduit toute interaction en éléments du système sous forme de méthode.
Comme c'est un peu limitant en terme d'abstraction, la communauté du dev (industrielle et académique) a fait des design pattern, des frameworks, qui permettent de palier ces limitations, et ça marche bien.
Mais dans les SMAs, enfin en tout cas dans ceux que j'étudie, on a une conception tellement proche du problème et tellement éloignée de l'implémentation, que ces "contraintes", ces limitations sont trop importantes, on a besoin pour implémenter son SMA d'abstraction ultra adaptées au problème (genre on veut pouvoir raconter dans son implem que notre agent envoie des messages, mais perçoit ses voisins, ce voisinage étant maintenu par l'environnement car il est dynamique et représente l'extérieur du système qu'on ne contrôle pas, qu'il y a des échanges en local mais aussi à distance, qu'ils ne doivent pas être gérés de la même façon par l'agent, etc, et d'autres trucs comme ça).
Et donc, mon truc permet de fabriquer ces abstractions adaptées au problème, ou plus précisément d'en réutiliser pour les composer et faire sa plateforme SMA maison.
C'est là qu'on fait le lien avec les ES, au final, ça semble permettre de définir et de réutiliser des systèmes entre différents jeux, pour les composer dans les entités et définir leur structure et leur dynamique de façon très adaptée et très proche du problème que l'on veut modéliser.
Et on peut mettre dans ces systèmes l'implémentation de ces différentes préoccupations de façon bien séparée.
Forcement, tout les gens qui bossent sur le jeux retrouvent leur billes sans aucun "gap" entre ce qu'ils ont dans la tête (des tanks qui se déplacent, qui ont une tourelle) et la façon dont c'est organisé dans l'implémentation (l'entité tank et tout les composants qui la concernent, et les systèmes qui l'intègrent au reste du monde).
En objet, chacun de ces concepts se seraient retrouvés un peu partout dans différentes parties du code il me semble.
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Oui, là la récursivité est un peu différente, c'est pas simplement un truc dans un truc, mais c'est un truc pour fabriquer un autre truc…
Bon, je sais pas, je crois que c'est juste différent, mais je suis très content de voir que mon approche ressemble à un paradigme qui est utilisé sérieusement dans l'industrie, ça veut dire que mon travail n'est pas complètement loufoque :)
Je dis ça parce qu'il est utilisable (et utilisé en pratique), mais il y a quand même beaucoup d'idées qui en font un truc élégant et beau théoriquement, mais qui en pratique est juste lourdingue à utiliser pour le moment (en particulier cette récursivité qui apporte la réutilisation et la composition des différents « aspects » (i.e. les systèmes des ES).
Je pense que j'y réfléchirais plus précisément pour en faire une analyse comparée dans le futur !
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Je ne suis pas sûr que ce soit vraiment comparable en terme d'abstractions : d'un côté on a des entités, des systèmes et des composants, de l'autre, on a des écosystèmes et des espèces qui ne peuvent exister qu'au sein d'un écosystème.
Mais si on triche un peu et qu'on fait un parallèle, alors un ES récursif serait un ES dont certaines des entités et/ou des systèmes sont eux-même définis par un ES, et que le lien entre le contenant et l'ES contenu soit cohérent avec les ES.
Tu vois l'idée ? Je ne suis pas sûr que ce soit applicable aux ES en fait…
Dans mon approche, en fait sans cette récursivité, ça sert à rien, on peut rien faire, un peu comme si on avait de la prog orienté composant mais sans composant composites : ce serait chiant :)
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Je pense que non, car mon approche ne permet pas d'implémenter des agents, mais l'architecture nécessaire à l'implémentation d'un agent :)
En gros, ça permet, par composition, de choisir quels mécanismes lient l'agent à son environnement.
Un peu comme les systèmes « lient » les entités entre elles et dans leur environnements selon plusieurs aspects.
Une façon simple de voir si c'est comparable ou non, c'est de répondre à cette question : comment tes agents interagissent entre eux et avec leur environnement ?
[^] # Re: Objection
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
C'est vrai, mais ça vient surtout, à mon avis, du fait que les outils de debug qu'on a actuellement on été fait pour autre chose que ce paradigme de programmation !
j'irais jusqu'à dire qu'avec des outils de debug ES sur du code ES, ce sera mille fois mieux que du debug OO sur du code OO :)
Il y a donc encore du boulot : l'argument de ton pote est valide dans une vision court terme !
# Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 6.
C'est « marrant », j'ai passé 4 ans de ma vie à faire une thèse sur l'aide au développement des systèmes multi-agents (SMA).
Un SMA : un truc avec pleins d'entités qui interagissent entre elles et qui sont régis par leur environnement sur certains aspects.
Ça vous fait penser à quelque chose ?
Les gens qui bossent sur les SMAs s'en foutent un peu de savoir comment ils sont implémentés, mais c'est ce à quoi je me suis intéressé.
Et la solution à laquelle je suis arrivée ressemble TRÈS fortement à l'architecture ES que tu viens de nous présenter.
Je parles bien de l'architecture de l’implémentation d'un SMA, et non pas de l'architecture des SMA eux-même : de la même façon qu'un jeu a une architecture différente selon les types d'entités représentées,leur comportement, leur capacités ; tout les jeux peuvent être implémentés en utilisant une architecture ES.
Ça prend la forme d'une grosse thèse, et puis d'une implem sous forme d'un langage de description d'architectures implémentables en Java.
Le modèle est plus « simple » qu'un ES, il est composé d'espèces et d'écosystème (le parallèle « serait » entité et système), il est récursif (des ES composés d'ES en quelque sorte) et s'appuie sur une brique de base qui est un peu plus riche qu'un composant logiciel (l'écosystème).
Le composant n'est qu'une version simplifié d'un écosystème au final.
C'est pas pareil, mais ça y ressemble quand même beaucoup et c'est pas étonnant, vu que les jeux vidéos ont des organisations qui sont très proches de celles des SMAs !
Je rentre pas dans les détails ici, si il y a des gens intéressés vous pouvez toujours vous taper ma thèse (http://www.irit.fr/~Victor.Noel/PhD/Dissertation) ou regarder l'outil d'aide au développment (http://www.irit.fr/~Victor.Noel/Projects/MAY) qui n'est bien sûr que trop peu documenté.