Bonjour,
Effectivement, comme je l'indiquais, le patch n'est pas très propre.
Dans le patch.V6, il reste des trucs du patch.V4 : dans la version 6 du
patch, nous pourrions supprimer les classes WifiPort, AggregatePort et
EthernetPort. Mais je n'ai pas osé car il y reste, peut-être, encore des
trucs. En fait, pour le patch.V6, le NetworkPort n'est plus une classe
abstraite, mais l'unique classe de gestion des ports (qui regroupe
tout). Cela explique la présence du NetworkPort::getWifiModes dans cette
classe concrète.
C'est une question de stratégie. Que proposez-vous : une classe qui gère
tous les types de ports (patch.V6) ou une classe par type de réseau
(patch.V4) ?
Concernant le découpage par étape, voici ce que je propose (bien
évidemment, on sautera les étapes que vous ne voulez pas) :
* Intégration des PCI_USB_ID dans les cartes et les manufacturiers ;
* Mise en place d'une gestion plus fine des jonctions entre les
cartes et les ordinateurs ;
* Évolution du DeviceNetworCard pour y intégrer les spécificités des
réseaux (Ethernet, Wifi,...) ;
* Intégration des réseaux (InternetNetwork, FQDN et FQDNlabel) et
ajout de la classe CommonImplicitTreeDropdown ;
* Création de la classe IPAddresse pour la gestion des adresses IP ;
Jusque là, les impacts sur les plugins d'import sont minimes.
* Création de la classe NetworkName (Nom réseau suggéré par David,
anciennement NetworkNode) en extrayant l'adresse IP du NetworkPort
et en supprimant de ce dernier les information de réseau (masque
et passerelle) ;
* Ajout des NetworkAlias ;
* Finalisation des NetworkPort (ajout des information Ethernet,
Wifi, ... ou création des classes filles EthernetPort, WifiPort, ...).
Damien
PS : pas de problème pour échanger par téléphone.
On 09/13/11 17:45, MoYo wrote:
Salut,
Effectivement à force de mettre bout à bout les éléments ca commence à
faire un patch énorme qu'il est difficile pour nous de décortiquer.
Il intègre en plus des évolutions très diverses : refonte de la
gestion des ports (séparation couche internet et liaison), aggregation
de ports, gestion du wifi
Une solution peut-être serait de voir les évolutions par pallier mais
je ne sais pas trop comment cela pourrait être découpé ?
Ensuite, j'ai vraiment survolé le patch et il est assez troublant
avoir une classe abstraite portent des informations spécifiques à ces
enfants. NetworkPort::getWifiModes par exemple.
L'abstraction de la classe NetworkPort me semble un peu bizarre vu
qu'on y fait des traitements génériques fonction de types filles.
Pour la 0.83, c'est encore jouable je pense mais il faudrait arriver à
valider complètement les différents éléments petit à petit.
Bref, avoir une version finalisée du pallier 1 avant de commencer le
second.
Il faudrait surement prévoir un moment pour discuter de tout ca et de
la façon de procéder (les patchs ce n'est pas une solution pour
avancer sur un aussi gros chantier).
Cordialement,
Julien Dombre
Le 12/09/2011 16:26, Damien Touraine a écrit :
Bonjour,
J'ai un petit problème : à force de mettre bout à bout des petits
trucs, j'ai obtenu deux très gros patchs (~ 380K :
https://forge.indepnet.net/attachments/960/patch.V4 et
https://forge.indepnet.net/attachments/962/patch.V6 appliquablent sur
la version 15646 du SVN de GLPI). Ils ne sont pas définitif. Mais, si
vous pensez que les modifications que je suggère sont intéressantes à
appliquer à GLPI, il me semble difficile, pour vous, de le vérifier
en détails avant de l'intégrer à GLPI. Donc, je ne sais pas comment
procéder. D'autant plus que cela ne me semble pas être le dossier
"chaud" de la 0.83 (ie : validation des nouvelles tab, épuration du
code, template sur les tickets, ...). Peut-être ce patch pourrait-il
attendre la version 0.84 ou une version ultérieur ?
Pour ces patch, j'ai essayé de tenir compte des commentaires de
chacun. Ils s'appuient fortement sur les deux pages du wiki que j'ai
initié
(https://forge.indepnet.net/projects/glpi/wiki/NetworkPortReview et
https://forge.indepnet.net/projects/glpi/wiki/Internet_Protocol_resources).
Cela facilitera la compréhension de ceux qui souhaitent en valider
les concepts et vérifier le patch. Notes que j'ai ajouter des points
supplémentaires à la page sur le NetworkPortReview (notamment, sur
les effets de bord de mes propositions sur les Device*Card et leur
jonction au PC).
Je suis conscient que cela chamboule beaucoup de choses pour les
plugins, notamment pour l'import d'OCS. Mais je particperai à la mise
du coeur de GLPI pour s'adapter à ces changements. Je m'attèlerai,
également, à l'outils de migration associé.
Ces deux patches sont une ébauche de ce qu'il est possible de faire.
Mais ils sont encore pollué par des essais intermédiaires. De plus,
ils ne sont par propre : ils ne purgent pas très bien les bases de
données lors la suppression de données. Mais ils donnent une bonne
idée de ce que je proposes.
Quoiqu'il en soit, avant de soumettre la version finale du patch, je
repartirai d'une distribution fraiche de GLPI directement issue du
SVN. J'y ajouterai les différents points que vous souhaiteriez voir
intégrer à GLPI. Je ferai, également, le tri dans le fichier de LANG
pour n'y laisser que le strict minimum. D'ailleurs, tout commentaire
sur les terminologies serait apprécié (à noter que le "Noeud réseau"
sera renommé en "Adresse Internet" à défaut de mieux).
Cordialement
Damien
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
--
--------------------------------------------------------------------
Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/)
Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64
--------------------------------------------------------------------
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
