Actuellement: 
UsersManager est un point single (il existe un UserManager.FO)
    public Collection<User> getUsers();
    public User getUser(String login);
    public void saxUser(String login, ContentHandler handler) throws SAXException;
    public void toSAX(ContentHandler handler, int count, int offset, Map parameters) throws SAXException;
Il existe les interfaces CredentielAware pour indiquer que ce user manager peut réaliser l'authentification aussi (vérification du mot de passe)
                      et Modifiable pour indiquer qu'on peut éditer ce user manager
On a des tas d'implémentations LDAP, SQL, Static...
--------------------------------------------------------------------------------------------------------------                                                                                                                                                               
Les problèmes:
  * si on a besoin de taper dans le LDAP + une base de données SQL on est obligé de coder un LDAP+SQLUsersManager
    quand on a un login 'ced', on sait pas s'il vient du ldap ou du sql... et si ça se trouve il y a un Ced dans les deux
    on est obligé de dire que LDAPSQLUsersManager est modifiable, du coup on peut modifier qq'un de pas le ldap et on se prend un tir (même si le meme login est dans sql)
  * dans le cadre d'une application à plusieurs workspaces (admin + cms + repo) on veut pouvoir avoir différentes bases de données
  * dans le cadre d'un cms web à plusieurs site on veut pouvoir avoir des bases utilisateurs différentes par site (et éventuellement plusieurs base pour 1 site)
  * le usersmanager de l'admin n'en est pas un      
--------------------------------------------------------------------------------------------------------------
Keep in mind:
Quand on parle de bases utilisateurs différentes, il peut s'agir de SQL+LDAP, mais aussi de SQL+SQL dans la même base ou non (attention aux collisions de nom de table...)
Un travail a été fait pour que les utilisateurs front soient potentiellement différents selon le site avec des logins sous la forme LOGIN#SITENAME. Quand on est sur le site SITENAME, on peut utiliser l'identifiant LOGIN
Une migration doit se passer en douceur, dans tous nos historiques et notre gestion des droits par exemple, on a juste un login comme information.
--------------------------------------------------------------------------------------------------------------
Fonctionnellement:
Les étapes suivantes sont à faire, soit à l'intégration (comme aujourd'hui), soit à la configuration, soit un peu des deux:
Il faut pouvoir créer des instances de UsersManagers parmi les implémentations existantes (et les configurer)
   par exemple, je crée un SQLUsersManager sur le pool de connection "core" avec l'identifiant 'cms-users'.
   + un LDAPUsersManager sur le pool de connection "core" avec l'identifiant 'cms-users2'
   + un XMLUsersManager sur le fichier "admin.xml" avec l'identifiant 'admin'
Puis j'associe ces users-manager à des workspaces, à des sites, ou à tout autres choses 
    par exemple le workspace cms utilise "cms-users" et "cms-users2" ; le workspace admin et jcr utilisent "admin"
    et puis dans le site 'intranet', je choisis uniquement 'cms-users2' 
--------------------------------------------------------------------------------------------------------------
Tâches:
UsersManager devient donc un point d'extension multiple.
  getUsersManagers(context) où contexte est une string, type : "workspace-cms" ou "workspace-cms/site-www"; et ça renvoie une map id<->UsersManager
  getUsersManager(id) qui renvoie un seul UsersManager, où c'est l'id du usersmanager. par exemple "cms-users" 
  getUsersManagers() renvoies les users managers utilisées par des workspaces.
Nettoyer la liste des implémentations existantes (slq+LDAP dégage)
Dans les interfaces, casse Modifiable en Editable + Modifiable
Ajouter une impl pour l'admin. EDITABLE NON MODIFIABLE. modifier le changement de mot de passe de l'admin => ça se passe dans users..
User doit avoir une méthode en plus pour renvoyer le prefix.
Un login stocké ressemble donc à LOGIN
Il faut un fichier de paramétrage workspace<->users managerS (WEB-INF/param)  ORDONNES                       
Il faut un paramètres multiple de site pour choisir parmi les users managers du workspace cms
Il faut faire fonctionner tous les getUsersManager
Dans l'interface d'admin, il faut gérer de pouvoir sélectionner le usersmanager à utiliser (attention, certaines sont modifiables, d'autres non !). C'est une liste déroulante AVANT la recherche. dans les usersmanager, il y a d'abord un ALL pour chercher un user. renvoyer des icones différentes selon le usermanager. le create n'apparait que si on sélectionne un usersmanager qui le permet explicitement
...