[ 5 mars 2009 : Mise à jour de l'article : Cocomo devient AFCS et passe en version 0.9.1, corrigeant quelques bugs et changeant le namespace de référence ]

Comme vous le savez maintenant ( cf.Hello AFCS ( Bye Cocomo ) ), l’objectif de Cocomo AFCS est de nous offrir, à nous les gentils développeurs Flex, un moyen simplifié d’intégrer des technologies de « collaboration en temps-réel » dans nos applications.

Nous l’avons vu dans l’exemple précédent, le principal composant d’une application Cocomo AFCS est le « gestionnaire de session » ( ConnectSession ou ConnectSessionContainer » implements IConnectionSession cf Documentation ). C’est lui qui permet à l’application de se connecter à un salon ( serveurs Cocomo AFCS /ConnectNow ), d’identifier les utilisateurs, et de « synchroniser des données en temps-réel » entre les différentes applications connectées.

Nous allons maintenant nous intéresser plus en détail à ces salons ( les « rooms ») et à leur fonctionnement.

Les salons Cocomo sont des « points de rencontre virtuels » à travers lesquels des applications clientes peuvent synchroniser des données, échanger des flux audio/vidéo et partager des fichiers. Pour permettre cette synchronisation, les salons stockent les données et transmettent les mises à jour aux différents clients « abonnés ».

Les informations stockées et partagées peuvent être de différents types ( cf. SharedModel ), mais fonctionnent tous sur le principe de « modèle de donnée partagé ».

Modèle partagé de donnée ( SharedModels )

Un modèle partagé est une classe dont les données sont en quelque sorte « stockées à distance » ( ici dans un salon Cocomo AFCS ). Pour assurer que tous les clients seront bien synchronisés, les mises à jour du modèle ne sont pas directement effectuées côté-client. Lorsqu’un client veut effectuer une modification sur modèle ( exemple : envoi d’un message sur le tchat ), la mise à jour est d’abord demandée au salon, côté-serveur. Le client envoie en fait un message contenant la modification voulue au salon, et c’est ce dernier qui transmet les nouvelles informations mises à jour à chaque client. De cette manière le nouveau message s’affichera ( quasiment ) en même temps chez l’émetteur et les destinataires du message. C’est ce mécanisme qui assure que les différents clients connectés partagent en permanence les mêmes données.

Cocomo AFCS ( les composants et les salons ) intégre un mécanisme de vérification des droits, par conséquent, lors de chaque « demande de modification », le salon va vérifier si l’utilisateur à l’origine de la « publication » est autorisé à l’effectuer. Par défaut, les droits sont distribués « en cascade » pour chaque modèle en fonction du rôle de l’utilisateur dans le salon. La modification des modèles partagés et des droits n’est autorisée qu’au propriétaire du salon ( cf. UserRoles.OWNER ).

Nous verrons prochainement qu’il est possible de créer ses propres modèles de données partagés, mais nous allons commencer par nous intéresser aux modèles « natifs » de Cocomo AFCS , ceux créés durant chaque session.

SharedManagers

Par défaut, les applications Cocomo AFCS gérent quatres « modèles de données partagés » de base, il s’agit en quelque sorte des informations minimales devant être synchronisées entre les clients pour permettre leur collaboration. Pour gérer ces modèles partagés « natifs », un gestionnaire de session dispose de quatre classes « SharedManagers« , chargées de se synchroniser avec les données « stockées » sur le serveur :

• l’état du salon : RoomManager
• les utilisateurs connectés : UserManager
• les flux audio/video échangés : StreamManager
• les fichiers partagés dans le salon : FileManager

À l’ouverture d’une session sur un client ( connexion et identification réussie ), le gestionnaire initialise et abonne ces quatre managers. Ces managers sont alors chargés d’échanger les données nécessaires avec le salon pour maintenir la synchronisation des différents clients.

( les UserModel, FileModel… représentés dans le schéma n’existent pas « réellement » sous ces noms, mais cela permet de donner une idée du mécanisme global )

RoomManager

C’est la classe chargée de synchroniser et de gérer l’état du salon :

• nom du salon : roomName
• url du salon : roomURL
• bande passante : bandwidth
• statut du salon ( session terminée, pas commencée, en pause … ) : roomState
• rôle par défaut des nouveaux participants : autoPromote
• entrée libre : guestHaveToKnock
• …

UserManager

Cette classe est chargée de synchroniser et de gérer la liste des utilisateurs connectés, ainsi que leur rôles / droits respectifs

• liste des utilisateurs connectés et liste par rôles ( owner, publisher, viewer ou lobby cf.UserRoles)
• rôle, ID de l’utilsateur en cours

StreamManager

Cette classe est chargée de la synchronisation et de la gestion des flux en cours d’émissions. Elle vous permettra par exemple de créer, de mettre en pause ou de stopper un flux.

FileManager

Cette classe est chargée de la synchronisation et de la gestion des fichiers partagés dans le salon. Elle vous permettra par exemple d’envoyer un fichier, de suivre l’avancement de l’envoi, ou encore de lister les fichiers stockés.

SharedManagers et gestion des droits

Initialement, le rôle et les droits de chaque utilisateur découlent de son rôle au niveau du salon, mais il est à noter que chaque SharedManager permet de gérer les autorisations sur son modèle respectif ( SharedManager.setUserRole(…) ). Vous pourrez ainsi définir, par exemple, que pour le partage de fichiers, l’utilisateur B aura le droit de publication, alors qu’il ne l’aura pas pour les autres modéles

CocomoDevConsole AFCSDevConsole

Le SDK de Cocomo AFCS contient une application nommée CococomDevConsoleAFCSDevConsole. Il s’agit d’une application AIR permettant d’observer et de gérer en temps réel l’état de ses salons, et donc de ses modèles de données partagés.

Une fois connecté et entré dans un salon, dans l’onglet « Manage », nous avons accès à :

• A. la configuration du salon
• B. les utilisateurs connectés
• C. les flux diffusés
• D. les fichiers partagés

Cette application peut s’avérer utile, mais nous allons voir qu’il est assez simple d’incorporer ces informations dans sa propre application.

Utiliser les SharedManagers

Voici un exemple d’application qui permet de voir comment récupérer ces informations directement sur les SharedManagers.

Voilà pour aujourd’hui…
La prochaine fois nous verrons comment utiliser les sharedManagers pour créer de nouveaux composant, avant de voir finallement comment créer nos propres modèles de données partagées.

A l’année prochaine …