14-02-2011, 07:33 PM
@Argorate : je pense que tu n'as pas saisi certains aspects de ce que j'aimerais concevoir.
Il ne s'agit pas de faire des mises à jours pour "personne", mais de proposer aux IA les nouveaux paramètres.
Je pourrais très simplement exécuter mes évènements avec des crons ou une connexion utilisateur dans une optique "classique", mais ce n'est tout simplement pas adaptés à mes besoins.
Prenons une pile de 10 évènements, si l'évènement 1 entraine des circonstances dans lesquelles l'évènement 2 ne se serait pas produit.
Et si l'IA concerné par l'évènement 2 décide de faire autre chose de plus profitable et donc supprime l'action 2 pour la remplacer par une action X qui sera placé dans la pile.
Cette nouvelle action interfèrera avec d'autres actions dans la pile, et même si tous les évènements ne seront pas concernés par un petit changement, il se peut que de grands changement se produisent au bout de quelques temps et après que le changement ait influencés de nombreuses actions.
Ceci est une explication assez maladroite de ce qu'on appelle vulgairement la théorie du chaos, je te conseille le très bon mais difficile d'accès (à mon gout) "La théorie du Chaos" de Gleick chez Flammarion.
Cette théorie est issue originellement des premières simulations météorologique, ou les scientifiques se sont aperçu qu'une erreur très loin derrière une virgule flottante avait entrainé des modifications radicale sur le modèle météorologique.
En conclusion, un tout petit changement dans ma base de donnée pourra avoir des effets important sur le reste à long terme, dans cette optique, je me dois d'actualiser les variable et de les soumettre à l'IA régulièrement.
J'espère ne pas avoir été trop vaseux :S
bref, comme tu le dis, dans un cas tout simple d'exécution procédural des scripts de la pile la solution d'exécution de script via utilisateur serait une solution viable.
Ensuite, la gestion en tache de fond de la base de donnée, par l'exécution en petites séquences exécuté de manière asynchrones permet d'après moi deux choses :
- Un énorme gain de temps d'exécution à l'évidence, vue que le temps d'exécution d'un script est réduit par le facteur de division qu'on lui applique.(ca se dit ça?)
Un script qui mettrait 10 secondes est divisé en 10 process exécutés simultanément, la base sera à jour en une seconde.
- Une facilité de maintenance évidente.
Bien sur il est tout à fait possible de fragmenter son code et de le ranger de manière claire et compréhensible même en codant en procédural, mais je pense que l'externalisation des taches est plus en adéquation avec la POO.
Après il faut relativiser, rien ne sert de sortir un bulldozer pour labourer le petit carré de terre du jardin, mais je pense que cette structure est plus adapté aux projets complexes et "lourds".
@niahoo : Effectivement, l'utilisation d'un langage différent pourrait être intéressant, tant du coté performances que pour l'intérêt d'explorer de nouveaux terrains, mais je trouve que le principal attrait de php, est sa communauté et l'engouement qu'il génère.
Partir de zéro sur un projet qui pourrait s'avérer me prendre des mois de codage et devoir apprendre un nouveau langage pourrait être un peu trop à la fois, en tout cas je ne m'en sent pas la force.
Certe php est incomplet, contient certaines incohérences et vides, mais il a l'avantage d'être très documenté.
Tu as cependant raison, si php m'impose trop de limite je devrais passer à autre chose, un Daemon en dur pourrait régler toute ou partit de ma problématique, mais j'explore encore le champ de mes possibilités.
Il ne s'agit pas de faire des mises à jours pour "personne", mais de proposer aux IA les nouveaux paramètres.
Je pourrais très simplement exécuter mes évènements avec des crons ou une connexion utilisateur dans une optique "classique", mais ce n'est tout simplement pas adaptés à mes besoins.
Prenons une pile de 10 évènements, si l'évènement 1 entraine des circonstances dans lesquelles l'évènement 2 ne se serait pas produit.
Et si l'IA concerné par l'évènement 2 décide de faire autre chose de plus profitable et donc supprime l'action 2 pour la remplacer par une action X qui sera placé dans la pile.
Cette nouvelle action interfèrera avec d'autres actions dans la pile, et même si tous les évènements ne seront pas concernés par un petit changement, il se peut que de grands changement se produisent au bout de quelques temps et après que le changement ait influencés de nombreuses actions.
Ceci est une explication assez maladroite de ce qu'on appelle vulgairement la théorie du chaos, je te conseille le très bon mais difficile d'accès (à mon gout) "La théorie du Chaos" de Gleick chez Flammarion.
Cette théorie est issue originellement des premières simulations météorologique, ou les scientifiques se sont aperçu qu'une erreur très loin derrière une virgule flottante avait entrainé des modifications radicale sur le modèle météorologique.
En conclusion, un tout petit changement dans ma base de donnée pourra avoir des effets important sur le reste à long terme, dans cette optique, je me dois d'actualiser les variable et de les soumettre à l'IA régulièrement.
J'espère ne pas avoir été trop vaseux :S
bref, comme tu le dis, dans un cas tout simple d'exécution procédural des scripts de la pile la solution d'exécution de script via utilisateur serait une solution viable.
Ensuite, la gestion en tache de fond de la base de donnée, par l'exécution en petites séquences exécuté de manière asynchrones permet d'après moi deux choses :
- Un énorme gain de temps d'exécution à l'évidence, vue que le temps d'exécution d'un script est réduit par le facteur de division qu'on lui applique.(ca se dit ça?)
Un script qui mettrait 10 secondes est divisé en 10 process exécutés simultanément, la base sera à jour en une seconde.
- Une facilité de maintenance évidente.
Bien sur il est tout à fait possible de fragmenter son code et de le ranger de manière claire et compréhensible même en codant en procédural, mais je pense que l'externalisation des taches est plus en adéquation avec la POO.
Après il faut relativiser, rien ne sert de sortir un bulldozer pour labourer le petit carré de terre du jardin, mais je pense que cette structure est plus adapté aux projets complexes et "lourds".
@niahoo : Effectivement, l'utilisation d'un langage différent pourrait être intéressant, tant du coté performances que pour l'intérêt d'explorer de nouveaux terrains, mais je trouve que le principal attrait de php, est sa communauté et l'engouement qu'il génère.
Partir de zéro sur un projet qui pourrait s'avérer me prendre des mois de codage et devoir apprendre un nouveau langage pourrait être un peu trop à la fois, en tout cas je ne m'en sent pas la force.
Certe php est incomplet, contient certaines incohérences et vides, mais il a l'avantage d'être très documenté.
Tu as cependant raison, si php m'impose trop de limite je devrais passer à autre chose, un Daemon en dur pourrait régler toute ou partit de ma problématique, mais j'explore encore le champ de mes possibilités.