Menu V2 : V2: general - l'API Web-AlternD - Les specs logicielles - Template et Bureau - Les specs, v2

Version 2.0

Fonctionalites / objectifs prioritaires

Voici les fonctionalites generales que nous visons pour la 2.0. L'idee generale est de corriger des lacunes de conceptions de la serie milestone:1.0. On cherche donc, dans cette liste, a documenter les choses qu'AlternC va faire et non ce a quoi AlternC doit repondre (les besoins) ou comment cela sera fait (les technologies).

Besoins / "requirements"

Ceci sont les contraintes que nous voulons imposer au developpement. Il ne s'agit pas ici d'imposer des contraintes techniques mais de lister une liste de besoins que le logiciel devra remplir. Idealement, on devrait partir d'une serie de cas d'utilisation et chaque module/developpement devrait repondre d'un cas et pouvoir etre verifie comme repondant (ou non) au cas d'utilisation.

  • portable: peut etre compile, package et deploye sur plusieurs plateformes, bien que notre focus sera initialement sur Debian (#714)
  • propre: ne remplace pas tous les fichiers et a un design solide et accessible (#473, #614, #497)
  • interface facilement modifiable (#37)
  • migration du milestone:1.0 possible de facon semi-automatique ou au moins avec une procedure bien definie
  • Tout en UTF-8, traductions, configs, locales...

Technologies

Certaines ont deja ete proposes :

  • Utilisation d'un systeme de template pour l'administration ( InterfaceUtilisateur )
  • Serveur XmlRpc / AlternD (AlternCv2/Api)
  • modulable a souhait ( EtatsDesPlugins? )
  • Core qui check toutes les 3 secondes les actions a faire ( au niveau de la base de donnees ) et effectue les actions, ce qui permet de ne pas toucher directement a partir de l'interface graphique et donc renforcer la securite
  • implantation en layers ModelViewController
  • TestUnitaires?
  • Permettre les grappes de serveurs
  • Gestion simple des traductions et de la generation de celles ci
  • Gestion d'un serveur Multi-IP ( permettre d'attribuer des clients a une ip )
  • Gestion des comptes admin/revendeurs/clients
  • Systeme de ticket entre revendeurs/admin et clients/revendeurs
  • Gestion avancee des logs, integration des logs d'apache, couriers, syslog, ... dans l'interface d'admin pour les admins
  • Installation des modules par l'interface d'administration ?
  • redesign des bases (#784)
  • SystemConfiguration: utiliser les logiciels de "GestionDeConfiguration?" deja connus (cfengine, lcfg, puppet, etc) pour gerer les configurations des serveurs, quitte a finalement faire une interface web pour ces engins...