-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour, Je crois que vous avez copié/collé deux fois le contenu de votre mail, je vais donc répondre à la moitié cela devrait suffire. Walid Nouh a écrit : (...), > Dans le cadre de notre projet, nous pensons déployer la future version > 0.7. Hors, on va avoir besoin de fonctionnalités particulières. Si elles > ne sont pas prévues dans cette version, je voudrais discuter de la > possibilité que nous fassions nous même les devs, et de savoir si > ceux-ci (et sous quelles conditions) peuvent être mergés dans GLPI. D'une manière générale, si une fonctionnalité correspond à un besoin générique et qu'en plus elle est déjà codée alors on essaye de l'intègrer dans GLPI afin que tous les utilisateurs en bénéficient. > Authentification : > * GLPI permet de remonter l'appartenance d'un utilisateur à un groupe > depuis l'annuaire LDAP, en regardant un attribut de l'objet user. > Seulement, dans le cadre de mon projet j'ai besoin de trouver cette > information, aussi, en parcourants des objets groupes et en lisant leur > attribut member. > -> pensez vous intégrer une telle fonctionnalité dans la version 0.7 de > GLPI. Sinon, si je la développe, pourra-t-elle être prise dans la > version 0.7 ? Humm, ça on l'avait pas prévu mais pourquoi pas si ça respecte la règle de merge (cf plus haut). > * Pour des besoins de performances, nous pensons disposer de 2 bases de > données pour GLPI : une maître en lecture/écriture, et une esclave en > lecture seule. Est-il possible de préciser que l'on veut effectuer les > lectures sur une base et les écritures sur une autre ? Actuellement non ce n'est pas possible simplement. Je me demande d'ailleurs quel est le différentiel de performances entre un serveur MYSQL bien dimensionné + frontaux et votre solution. Je n'ai pas de réponses mais je serai intéressé par des retours. > -> même question, pensez vous développer cela pour la 0.7, et sinon est > ce que si je développe cette fonctionnalité elle pourra être mergée dans > le CVS ? Non ça n'est pas prévu et ça me semble un peu fastidieux à faire étant donné qu'on a pas terminé le clean code. > * Avec quelle volumétrie avez vous testé la base de GLPI. Notre cible > est de répertorier 80 000 machines à terme. Pensez vous que l'interface > va répondre de manière convenable ? Si tel n'est pas le cas, envisagez > vous de faire des amélioration pour la version 0.7 ? L'objectif de la 0.65 était l'optimisation des requêtes et de l'interface pour permettre une utilisation sur grands parcs. Nous visions entre autre des parcs de 50 000 à 80 000 machines. Ensuite avec la 0.7 et sa gestion multi-entités, les points de congestion seront trés limités. Nous sommes toujours prêts à faire des améliorations dans ce sens. > * sur la partie HelpDesk, je n'ai pas trouvé (mais c'est possible que ça > existe) un mécanisme d'escalade. En effet, le but c'est que si la > personne en charge du ticket ne sait pas répondre au problème, qu'elle > puisse inclure dans la boucle une ou plusieures personnes aux > compétences suffisantes. Avez vous déjà réfléchi à cette fonctionnalité > ? Nous en avions discuté entre nous mais c'est resté à l'étape d'idée pour des développements futurs. Si vous avez des suggestions : you 're welcome. %<------------------------------------------------------------------------ (surpression du cop/col) Cordialement, - -- Jean-Mathieu Doléans -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEu24XyQar2dfQ77ARAsB0AJ9PfwR4HVxBBf0L5m1+5jP6v+7aWwCeIvfk 4TmOR1I4tL+JVAHHhsbiSL0= =U7EN -----END PGP SIGNATURE----- _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
