system.process based signals only ?

[eKameleon]

Hello :)

Après avoir expérimenté en Javascript une nouvelle version du package
system.process en le basant uniquement sur le package system.signals
et sans propagation événementielle basée sur le Event Model W3C (que
j'ai pourtant développé également en JS), je me demande donc si je ne
devrais pas faire de même en AS3 et du coup basée les notifications
(notifyStarted, notifyFinished, etc.) uniquement sur les signals.

L'idée au final est de rendre les process super rapide et uniquement
basées sur une propagation très simple (basée sur les Vectors)

A savoir que pour le moment la version AS3 diffuse déjà des messages
sur le mode signals et également sur le mode événementiel W3C. Du coup
je peux conserver cette dualité mais est ce bien utile ?

Je peux à la rigueur conserver la notification sur le start et le
finish avec un ActionEvent.START et ActionEvent.FINISH et du coup il
faudrait abandonner les propagations sur les autres méthodes
notifyProgress, notifyChange, notifyStopped, etc.

Qu'en pensez vous ?

EKA+ :)

[qatab chakir]

Salut , je suis vraiment impressionné par ce modèle événementiel , et j'étais le premier a solliciter son implémentation dans vegas et du coup l'IoC , mais le probleme c'est qu'on peut pas completement zappé le Event Model W3C , du fait qu'il est natif et forcement utilisé pour les évènement IO , a part qu'on est habitué a ce mode de développement ,ce-qui serai un peu difficile de switcher vers l'autre ,
Et donc la question que je me pose est ce-que ça vaut vraiment la peine de changer ? et c'est quoi le gain en % ?  y avait il un vrai bench , pour mesurer vraiment la différence de performance , et dans quelle type et taille d'application qu'on pourra avoir un problème de performance due a la propagation événementielle ?

chakas3

[eKameleon]

Hello :)

J'ai pas besoin de changer les events là où ils se trouvent ;) Ici je
parle juste du package system.process qui utilise en AS3 les signals
et les events et qui en JS utilise uniquement les signals, pour des
raisons simples car en JS le modèle événementiel n'est pas natif, car
le JS selon les supports (navigateur, etc) ne fonctionne pas à la même
vitesse, avec les mêmes implémentations etc. du coup bien maitriser la
propagation des notifications avec les signals et tout de même plus
efficace que la grosse machinerie du modèle événementiel W3C.

Pour moi faut pas tout confondre et les 2 sont indispensables dans une
application : events + signals

Maintenant pour revenir au system process la seule chose c'est que si
je fixe sans prévenir ce changement, en virant les events d'un coup
cela risque de perturber certains utilisateurs actuels du
frameswork ;) Du coup je préfère commencer à en parler ici avant de
m'y mettre pour les prochaines versions de VEGAS :)

Sinon pour le bench pas besoin d'en faire :

1 - les signals dans VEGAS sont basés sur des Vectors pour propager
les messages simples
2 - les events en AS3 sont super puissants mais sont lourd avec toutes
les notions de sécurités, etc dans le code natif du flash player.

Exemple quand ton fais un dispatchEvent(new ActionEvent("finish")) à
chaque fois dans un notifyFinished d'un process à chaque fois on crée
un nouveau event (pas possible de faire autrement) et donc on solicite
la création d'un nouvel objet avec l'exécution d'une nouvelle fonction
constructeur, etc... autant de temps perdu pour pas grand chose.

Ensuite faut pas oublier que dans les objets non graphiques (UI) la
propagation événementielle en bubbling et capturing n'est pas
fonctionnel en AS3... etc. etc.

Bref faut bien maitriser les 2 types de propagations de messages et à
mon sens ce sera plus simple d'avoir seulement des signals en AS3
comme en JS.

Autre point intéressant. Si l'on veut utiliser system.process dans
Tamarin (AS3 pour virtual machine AVM2 de Mozilla) il y aura des
problèmes car le flash.events.* n'existe pas dans Tamarin.

Bref pas mal de soucis pour un moteur de taches qui doit rester rapide
et souple.

Dans l'ioc de VEGAS dans tous les cas j'ai ajouté la prise en compte
des signals comme pour les events (attributs receivers et listeners
dans les définitions d'objets) du coup aucun soucis d'utiliser l'un ou
l'autre.

Pour finir je reste toujours à fond W3C event model pour faire du MVC
basé FrontController, au niveau de l'UI etc. Mais il faut apprendre à
prendre ce qu'il faut dans una application. Là je réfléchis pas mal en
ce moment à des applications pour Android (téléphone mobile, etc.) et
il faut arriver à penser que les events seront pas toujours bon pour
ce type de support.

EKA+ :)

On 19 juil, 12:54, qatab chakir <javacha...@gmail.com> wrote:
> Salut , je suis vraiment impressionné par ce modèle événementiel , et
> j'étais le premier a solliciter son implémentation dans vegas et du coup
> l'IoC , mais le probleme c'est qu'on peut pas completement zappé le Event
> Model W3C , du fait qu'il est natif et forcement utilisé pour les évènement
> IO , a part qu'on est habitué a ce mode de développement ,ce-qui serai un
> peu difficile de switcher vers l'autre ,
> Et donc la question que je me pose est ce-que ça vaut vraiment la peine de
> changer ? et c'est quoi le gain en % ?  y avait il un vrai bench , pour
> mesurer vraiment la différence de performance , et dans quelle type et
> taille d'application qu'on pourra avoir un problème de performance due a la
> propagation événementielle ?
>
> chakas3
>

[qatab chakir]

merci , tu as largement  répondu sur mes interrogations , et en tous cas sur FP10 faut vraiment revoir beaucoup de nos méthodes pour aboutir a une vraie optimisation de performance , en utilisant les signals , les Vectors , 3D native API  ..., d'autre part j'opte pour l'idée de laisser les deux modèles évènementiels dans system.process , et laisser au développeur le choix ,si c'est possible de définir le mode de propagation comme paramètre  .en laisant l'ancien comme mode par défaut.

[ekameleon]

Hello :)

je vais y réfléchir :) 

EKA+ :)