2. Concepts

Résumé :
Pour mieux appréhender la plateforme web « Les Fûts », partageons ensemble quelques concepts élémentaires qui fondent l'application.

Utilisateurs et associations

Chaque association a son site spécifique, visible publiquement par tous, en mode « invité ».

Un utilisateur enregistré, c'est-à-dire un membre d'une association chez les Fûts, dispose d'un accès personnalisé au système. Cet accès unique lui permet de naviguer dans les sites de toutes les associations chez les Fûts dont il est membre.

Actions et messages

En général, une action est ce que fait un utilisateur auprès d'un système. Par exemple, l'utilisateur peut publier des messages dans un blog, laisser un commentaire, publier un document, notifier que tel événement va avoir lieu à telle date...

Noter que les actions sont à différencier des tâches de consultation, telles que la lecture, la recherche, le téléchargement de documents depuis le site.

Dans les Fûts, ce sont les messages qui portent les actions, et non les

Lorsque le système permet à un utilisateur d'effectuer une action, en interne l'action est traduite sous forme de message, et ce message est stocké pour mémoire.

Ainsi, les articles de forums, et les commentaires, sont des messages publiés.

Mais tout message n'est pas forcément publié. Par exemple, l'action de créer un nouvel utilisateur, produit bien un message stocké en interne, mais ce message n'est pas publié en tant que tel.

Versioning des objets métier

Les objets métier sont versionnés, et leurs versions antérieures sont accessibles en ligne.

Il y a une réflexion à mener par la suite sur la possibilité de gérer des modifications concurrentes pour un même objet métier. Exemple : depuis un site associatif, on change l'adresse de tel utilisateur, et en parallèle sur un autre site associatif on change son numéro de téléphone. Comment se résout le « conflit » ?

Accès à des informations privées

Chaque site associatif a ses propres données sur son site applicatif.

Mais, en attendant mieux, les données des sites associatifs sont également centralisées sur le serveur métier. Cela pose donc un problème d'hébergement de données privatives.

En particulier, lorsqu'on connaît le niveau de sécurité de la v1.0...

Les conditions d'utilisation devront clairement poser le problème et donner la position des Fûts sur le sujet.

Vie privée

En attendant mieux, les données des sites associatifs sont centralisées sur le serveur métier. Cela pose un problème d'hébergement de données privatives.

En particulier, lorsqu'on connaît le niveau de sécurité de la v1.0...

Les conditions d'utilisation devront clairement poser le problème et donner la position des Fûts sur le sujet.

Mentions légales

Les droits et la responsabilité sur le contenu des sites associatifs doivent appartenir aux associations elles-mêmes.

Le problème, c'est qu'avec le système de centralisation, dans le cas où une erreur de distribution survient, comme par exemple un envoi sur un site associatif de données appartenant à un autre site associatif, il faut que tout existe pour régler le problème.

Donc d'une part il faut régler un problème de non-répudiation : savoir dire en cas de litige que c'est bien telle association qui a écrit tel contenu.

Et d'autre part il faut bétonner les clauses juridiques.

Open source

Le code PHP et l'architecture PHP/MySQL déployés sur les serveurs applicatifs devraient passer en open source, avec une licence non restrictive, de type Apache ou BSD.

Le code Java sur le serveur métier n'a pas de raison de passer en open source.

L'architecture applicative PHP présente des APIs pour être sollicitée par callback par le serveur métier. Ces APIs doivent être publiques, et des exemples d'implémentation, donc en premier chef le code PHP qui est déployé par les Fûts, doivent être disponibles.

Le serveur métier J2EE présente des APIs pour être sollicité par les serveurs applicatifs. Ces APIs doivent être publiques, mais l'implémentation peut rester privée dans un premier temps.

3/8 DÉBUT PRÉC. SUIV. FIN SOMMAIRE INDEX GLOSSAIRE