-->[]

Après avoir tourné l'idée dans plus ou moins tous les sens, j'en suis arrivé à un modèle théoriquement assez intéressant, puisqu'il s'agirait d'un calendrier complètement décentralisé. Les deux éléments-clés de cette organisation sont les acteurs et les évènements. Ces deux types d'éléments seraient a priori parfaitement représentables par des identifiants personnels, des entités avec lesquels on peut intéragir. Il n'y aurait donc pas un stockage centralisé d'un calendrier sous forme de base de données ou de fichier, mais un calendrier réparti de partout sur le net, ou plus exactement plein de calendriers qui s'entrecroisent.
Une autre notion importante est la notion d'acteur. Un acteur peut être bien sûr une personne, mais encore un lieu ou une ressource matérielle. En effet, un rendez-vous peut très bien être organisé entre 2 personnes (par exemple) sans emplacement précis, ou entre un rétroprojecteur, une salle, et 4 personnes, etc. L'autre point commun entre ces 3 types d'acteurs, c'est qu'on aimerait bien pouvoir consulter leur planning pour connaître leurs disponibilités: emploi du temps de Toto, planning d'occupation de l'amphi Trucmuche, ou disponibilité de l'ordinateur portable de la boîte.

Autre notion (c'est vraiment du vrac, mais c'est normal), c'est celle d'invitation: on peut avoir envie de convier par exemple la salle de réunion au rendez-vous de mardi entre 14 et 15h, et elle peut refuser parce qu'elle est déjà prise ou parce que ça lui pose un problème qu'il y ait autant de monde (bien sûr c'est le service logistique qui parlera en son nom, par exemple). L'amphi peut par contre proposer sa présence à ce rendez-vous, dont il aura appris incidemment l'existence. Libre alors à l'événement d'accepter ou pas.

On voit alors que le point d'ancrage de ce type d'organisation, ce sont les événements. Un événement est une entité, qui a un libre arbitre, peut accepter des gens dans son univers, et réciproquement demander à un acteur de l'accepter dans le sien. Hmm, ça me fait un peu penser à Jabber ça.

On peut demander à un acteur de fournir sa liste d'évènements, ou lui demander si à un instant T il est libre ou non. Par exemple demander au vidéoprojecteur s'il est libre mardi entre 17h30 et 18h. (Bien sûr, le fait qu'il soit libre n'implique pas automatiquement son acceptation à toute invitation.)
On peut également demander à un événement de fournir sa liste de participants, ou ses informations personnelles: dates, petit nom, description, peut-être même carte de visite au sens large (numéro de téléphone par exemple).

La modélisation de ces entités sous forme de contacts Jabber me semble a priori une bonne modélisation. Le mécanisme de présence et surtout de liste de contacts me semble un bon point.
Les autres avantages les plus appréciables sont, surtout, ceux-ci:
1. Les entités peuvent être réparties.
2. Un calendrier peut très bien avoir un sens au sein d'une entreprise, par exemple l'occupation de la salle de réunion, et ne pas en sortir car les événements seront des entités inscrites sur le serveur Jabber interne. De cette façon les participants pourront dire au monde qu'ils ne sont pas disponibles à telle date, mais l'événement associé ne sera pas visible de l'extérieur.

Cette modélisation soulève quelques problèmes, aussi.

Comment diffuser les informations d'un événement ? Certes, l'événement peut maintenir en interne une liste des personnes présentes par le moyen évident du roster. Le mécanisme d'autorisation peut représenter la confirmation de présence. Il peut même les classer par groupes (lieu-ressource-personne pour commencer, peut-être). Symétriquement, un acteur peut garder les événements auxquels il est inscrit, et utiliser aussi le mécanisme d'inscription pour savoir à quels événements il est autorisé ou pas.
Il faut cependant un moyen de diffusion de ces informations, car le roster n'est pas publiquement consultable. Des mécanismes existants devraient pouvoir nous aider, peut-être pubsub.
Enfin faut voir, mais à mon avis c'est faisable, et sans rajouter de JEP ou de namespace, principe auquel j'aimerais me tenir autant que possible: étant donné tout ce qui existe déjà, il est largement possible de remplir le but recherché en utilisant de manière appropriée des mécanismes existants.

Autre question: gestion des groupes. Il est peut-être possible qu'un groupe soit finalement juste un acteur, avec une liste de contacts. Pas encore assez réfléchi à ça, mais le problème n'est pas trivial a priori.

Autre question: alarmes ? Le CAP devrait pouvoir nous aider. C'est important mais pas bloquant pour l'instant.

Les principes importants auxquels j'aimerais me tenir sont les suivants:
- Jabber me semble une bonne architecture de base, notamment par le fait que ce protocole permette facilement la possibilité d'un calendrier réparti très efficace.
- Réutiliser au maximum les extensions de protocole existantes, du moins tant que ça a du sens. Elles sont très intéressantes, et construites de manière suffisamment souple pour permettre d'accomplir largement ce qu'on veut faire.
- Conserver la philosophie d'un strict minimum de complexité côté client.

J'ai sûrement oublié des choses, mais de toute façon j'approfondirai l'idée au fur et à mesure de mes réflexions. Le blog n'est peut-être pas le bon support pour ça, peut-être un wiki serait-il plus adapté ? On verra. Enfin ça permet déjà l'intervention des gens pour enrichir tout ça.