Re: [Glpi-dev] Romanian Translation

2006-07-21 Thread JMD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bogdan Susala a écrit :
 We've installed glpi and liked it a lot.

Thank you for your interest in GLPI.

 I saw the current Romanian
 translation and, besides the fact it's not finished, I have many
 objections to the already work done. Please tell me what is the
 procedure (I saw something in the Forum about a translation engine
 etc.). Should I talk to Alin? I clearly prefer to start from scratch.

I've create an account for you in the glpi translation application.
You should receive your login by mail.

You could modify each entry in the dictionnary. You could discuss about
it with Alin. There's no problem.

 Also, after refining the translation, I already have some interface
 improvements proposals, with regard to the ergonomy. Is there any
 mechanism of templating or theming?

Actually there is not mechanism of templating. Theme could be done with CSS.

I think it would be a work way in the future.

Best regards

- --
Jean-Mathieu Doléans
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEwJ6+yQar2dfQ77ARAj2uAJ4/ktmozUAPQp0N/U9Gjwp8IblD6gCdFuMt
wrrteJQZrKusEh87XN9MeZQ=
=1khX
-END PGP SIGNATURE-

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] ideas for a database abstraction layer

2006-07-21 Thread Marco Gaiarin
Mandi! Antoine
  In chel di` si favelave...

 What do people feel about db abstraction layers - can we introduce a

...they are good things, that, apart open the codebase to wider worlds
;), can aid to make better code.


 dependency for 5.0, 5.1? Would PDO be the best place to start? Or
 simply abstract everything out into functions and use db-specific
 functions?

AFAIK there's out there a plently of ``abstraction layer'', as the
first option i think it is better to look at them...


The real question is: we need a ``soft'' abstraction layer, because we
use the DB as a mere data repository and so we need only some cosmetic
changes on query, o we need a ``hard'' abstraction layer, because we
want to use hardly the DB (triggers, referential integrity, ...) and so
we need an abstraction layer that also reimplement some DB logic if not
here?

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it  tel +39-0434-842711  fax +39-0434-842797

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] plugin licences

2006-07-21 Thread Oliver Henriot

Hi all,

Dans sa grande sagesse, patben a écrit, le 20.07.2006 18:38 :
That's more or less what I had envisaged, except that I don't see the 
interest of having a class and a subclass. Could you detail your line of 
thought?


This would allow you to find also how many Acrobat Reader 7.0 do you
have and how many 7.1, for instance.
  
Well, GLPI already provides this subclass vision in this case, so I 
think it's a bit superfluous, and from a licencing point of view, there 
is no distinction between the two. It's not a bad idea as such, but I 
fear it will add too much granularity to the plugin.


Does anyone else on the list have an opinion on this point?


[cut]
MOLP, but on the other hand it is a kind of update...  
  

OK. I don't know much about this type of licence, I'll have to google it.


IIRC this is Microsoft Open Product License.
  

Indeed. https://partner.microsoft.com/global/40010504
It's pretty close to a full licence but there's no problem in adding it 
to the list ;-)


Cheers,

--
Oliver Henriot, Fédération IMAG, http://www.imag.fr/
Informatique et Mathématiques Appliquées de Grenoble
Direction des Moyens Informatiques
Domaine universitaire BP53 / 38041 Grenoble cedex 9 / France
tel.: +33 4 76 51 43 48  fax: +33 4 76 51 47 15

Trust in CNRS's certificates: http://igc.services.cnrs.fr/Doc/General/trust.html 



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] Mise à jour de la docume ntation GLPI, LDAP et Active Directory

2006-07-21 Thread JMD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Walid Nouh a écrit :
 
 Suite à mes tests avec LDAP, j'ai mis à jour la doc GLPI, LDAP et
 Active Directory http://glpi-project.org/article.php3?id_article=33
 qui se trouvait dans Documentation.

Merci du retour, j'ai complété l'article en ligne avec vos propositions
de modifications.


Cordialement,

- --
Jean-Mathieu Doléans
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEwKUFyQar2dfQ77ARAspzAJ0XmINjx7iIViZof8S+e1MjAGu5kACfYt0s
AAB5RfQHtxXUsQFCTFwCWNE=
=FIUg
-END PGP SIGNATURE-

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] LDAP, documentation etc...

2006-07-21 Thread JMD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Bonjour Walid,


Tout d'abord je dois vous présenter nos excuses pour le peu de
réactivité dont nous faisons preuve en ce moment.

Julien est en vacances bien méritées et moi je suis victime d'une
overdose momentanée de GLPI conjuguée avec d'autres priorités.

Bref, tout cela n'est que temporaire et nous ne manquerons pas d'étudier
 avec soin vos propositions de modifications et de patchs.

Je vous remercie personnellement pour votre démarche qui consiste à
arriver avec des questions, des propositions mais surtout des
**contributions**.

J'ai une nette préférence pour ceux qui brandissent une truelle plutôt
que des grenades accompagné d'incantations Yakas, Fokon.


Cordialement,

- --
Jean-Mathieu Doléans

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEwKelyQar2dfQ77ARAoriAKCD0/A5iT3t2K39iXPD1/DMoeBwBgCeMtru
/TOZjkncSdnYeEB2Uo80/r4=
=cKzH
-END PGP SIGNATURE-

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] Intégration support autres bases

2006-07-21 Thread JMD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Antoine a écrit :
 Salut,
 (J'écris en français parce que bon, je suis en france, mais si c'est
 mieux en anglais je suis néo-zélandais...)

En français, ça me demande moins d'efforts pour répondre et en ce
moment, je suis fatigué ;)

 Bon, je vois que dans le roadmap il est plannifié de supporter les
 autres bases avant la version 1.0.

Avant, pendant ou aprés La roadmap est indicative est surtout trés
fortement dépendante des énergies dont nous disposons.


 Si ça va pas être trop chiant je
 pourrais le tenter. On a un technicien qui utilise glpi/ocs pour gérer
 notre parc et il est HYPER content avec - seul problème - le patron
 lui dit qu'il va tout supprimer parce qu'à terme tout doit entrer dans
 notre ERP, et l'ERP est sous Oracle. Lui, il sait qu'il aura toute les
 fonctionnalités de glpi dans notre erp d'ici 2050, donc j'essaie de
 trouver une solution... On pourrais faire des bidouilles à droite et à
 gauche (liens odbc et machin), mais bon, la meilleur solution sera de
 l'intégrer dans notre base erp (bon, pas tout à fait propre mais mieux
 quand même !).

;)

 A qui est-ce que je m'adresse pour avoir des infos sur le sujet ? 

Vous êtes au bon endroit.

 Je vais jeter un coup d'oeil sur le code, mais s'il y a qqn qui pourra me
 renseigner sur le planning de l'implémentation et autre, on pourrait
 commencer à le faire...

Sans vouloir vous décourager, c'est pas le genre de chose qui va être
simple à faire. C'est d'ailleurs pour ça qu'on l'a pas encore fait.
Contrairement à ce que certains pensent ce n'est ni par fainéantise ou
par incompétence mais tout simplement par manque de ressources humaines
(ou financières qui permettraient de financer des ressources humaines)
pour le faire.

Le préalable à l'utilisation d'une couche d'abstraction permettant le
support d'autres bases est une réorganisation du code de GLPI. Ce à quoi
nous travaillons progressivement mais c'est long et surtout pénible.


Ensuite il faut sélectionner la couche la plus pertinente pour GLPI :
Adodb, PDO, Créole

Le souci c'est que certains chemins, nous coupent obligatoirement de PHP4...

Bref il nous manque une étude exhaustive des possiblités avec points
forts/faibles/conséquences et évaluation des temps nécessaires pour
prendre une décision.

C'est aussi pour cette raison que nous continuons à
cleaner/factoriser/réorganiser le code de GLPI afin de préparer le terrain.


Cordialement,

- --
Jean-Mathieu Doléans



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEwLFVyQar2dfQ77ARAqMQAJ44UKNeF6TDA34cfvk+DEGIHYAX5ACeMwpn
a4xgycwpNIy/t6dn+t4eGMc=
=bnH0
-END PGP SIGNATURE-

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] Intégration support autres bases

2006-07-21 Thread Antoine

Salut,


Le préalable à l'utilisation d'une couche d'abstraction permettant le
support d'autres bases est une réorganisation du code de GLPI. Ce à quoi
nous travaillons progressivement mais c'est long et surtout pénible.


je sais que c'est pas tip-top, mais est-ce qu'on pourrait pas, pour
dépanner, extraire les fonctions dans un module (toutes les fonctions
mysql) ? Cela permettra, en attendant la réorganisation du code,
d'intégrer d'autres bases plutôt facilement. Je sais pas trop comment
ça se passera au niveau dépendences (de compilation/modules), mais
cela devra pas être très difficile, non ? Toutes les fonctions
retourneront des structures/tableaux du même format, donc rien d'autre
à changer... Après tout, cela nous indiquera l'emplacement de toutes
les fonctions spécifiques, et donnera (au moins à moi, et mon patron
est presque d'accord pour que je passe du temps dessus...) une vision
de ce qui sera nécessaire de passer à une couche d'abstraction.


Ensuite il faut sélectionner la couche la plus pertinente pour GLPI :
Adodb, PDO, Créole

Le souci c'est que certains chemins, nous coupent obligatoirement de PHP4...


Au moins la solution décrite au dessus nous permettra de rien changer
au niveau dépendences vis-à-vis la version de PHP.


Bref il nous manque une étude exhaustive des possiblités avec points
forts/faibles/conséquences et évaluation des temps nécessaires pour
prendre une décision.

C'est aussi pour cette raison que nous continuons à
cleaner/factoriser/réorganiser le code de GLPI afin de préparer le terrain.


Bon, ma solution n'en est pas une vraie, mais elle vous gène
enormement ? Je pose la question parce que faire la même modif n fois
à chaque nouvelle version...
Bon, je finis par vous remercier de votre excellent travail - je suis
tout à fait conscient que vous avez plein de trucs en dehors de ça et
que chaque modif/amélioration et du bonus pour nous !
Cheers
Antoine
ps. Je vais tenter l'extraction ce weekend et si j'arrive à faire qqch
de propre je mettrai la diff qqpart pour que les intéressés puissent
jeter un coup d'oeil.

--
This is where I should put some witty comment.

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] LDAP, documentation etc...

2006-07-21 Thread Walid Nouh


Bonjour,

pas de soucis, j'ai besoin de produit, si les améliorations que 
j'apporte permettent de faire évoluer le produit j'en suis ravi ;)


je monte actuellement une maquette d'ocs + glpi avant le déploiement 
pour de vrai (à terme 80 000 postes), alors c'est pour ça que j'ai plein 
de questions (on veut pas se rater quoi...)


j'espère que mon patch sur les groupes ldap pourront être intégré à la 
prochaine version de glpi.


cordialement.
walid.

*
Le contenu de ce courriel et ses eventuelles pièces jointes sont
confidentiels. Ils s'adressent exclusivement à la personne destinataire.
Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur,
et afin de ne pas violer le secret des correspondances, vous ne devez pas
le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer
à l'émetteur et de le détruire.

Attention : L'Organisme de l'émetteur du message ne pourra être tenu 
responsable de l'altération
du présent courriel. Il appartient au destinataire de vérifier que les
messages et pièces jointes reçus ne contiennent pas de virus.
Les opinions contenues dans ce courriel et ses éventuelles pièces
jointes sont celles de l'émetteur. Elles ne reflètent pas la position de 
l'Organisme
sauf s'il en est disposé autrement dans le présent courriel.
**

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev