[Fusioninventory-devel] FusionInventory-Agent for Android devices

2011-06-06 Par sujet Walid nouh

Hi Kévin,

Can you merge the changesI did on the Android Agent into the master branch ?
My branch is here : https://github.com/wawax/fusioninventory-android

It would be great if you could quickly fix the stability issues because 
we're close to releasing at least an RC version and let people test it .



Walid.



___
Fusioninventory-devel mailing list
Fusioninventory-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel


Re: [Fusioninventory-devel] new generic injection feature

2011-06-06 Par sujet Gonéri Le Bouder
2011/6/5 Guillaume Rousse guillomovi...@gmail.com:
 Hello.
Hello Guillaume.

 Reusing already-existing XML inventory format for this file seems the
 best idea, as users are expected to know it already. It just adds an
 useless top-level node around the content:
The YSON format will quickly be the default option. We can support
both instead?
http://forge.fusioninventory.org/projects/fusioninventory-agent/wiki/API-REST-inventory

Best regards,
-- 
     Gonéri Le Bouder

___
Fusioninventory-devel mailing list
Fusioninventory-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

[Fusioninventory-devel] new generic injection feature

2011-06-06 Par sujet Sébastien Dagnicourt

Hello,
Of course I disagree a bit with that ... ;) 
First, the ByHand workaround is documented. A little only, but it is.
Second, the goal was to provide an easy way for users to add software scripts. 
I mean, as an ocs/glpi administrator, I don't have ( and I don't want) to check 
or modify the scripts that users deliver to me.  I just have to copy them at 
the right place (or better : users just put them at the right place). 
Even if the XML way permits more things than software discover, if ByHand is 
removed,  I will have to:
 1) Inform users where they have to write the output of their scripts 
 2) Check that the output is correct
 3) Change all scripts already in place.

And I don't to have this work :)

Best regards,

Sebastien.


  ___
Fusioninventory-devel mailing list
Fusioninventory-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel

Re: [Fusioninventory-devel] new generic injection feature

2011-06-06 Par sujet Guillaume Rousse
OK, I think I found the user of this hack :)

Le 06/06/2011 14:33, Sébastien Dagnicourt a écrit :
 Hello,
 Of course I disagree a bit with that ... ;)
 First, the ByHand workaround is documented. A little only, but it is.
Do you really consider comments buried in the perl module a
user-targeted documentation ? I don't.

 Second, the goal was to provide an easy way for users to add software
 scripts. I mean, as an ocs/glpi administrator, I don't have ( and I
 don't want) to check or modify the scripts that users deliver to me.  I
 just have to copy them at the right place (or better : users just put
 them at the right place).
 Even if the XML way permits more things than software discover, if
 ByHand is removed,  I will have to:
  1) Inform users where they have to write the output of their scripts
Anywhere, that's the point of using a command-line switch instead of an
hard-coded location.

  2) Check that the output is correct
It's far more easier to check a file content, wether generated by a
script, or manually produced, than a script supposed to produce this
content. Especially when this script has been written by someone else
without any coding style reference, and you don't have access to the
host where this script is supposed to run...

  3) Change all scripts already in place.
 
 And I don't to have this work :)
Why upgrade then ? If you're happy with 2.1.x branch, you don't need to
switch to 2.2.x one.

Of course, I'm interested about any alternative proposal, but:
- it should not be software (or any other category) specific
- it should not run untrusted external code, especially as root user
- it should be documented at user-level
- it should be tested (by some kind of automated regression test, not
just user-approved).

-- 
BOFH excuse #300:

Digital Manipulator exceeding velocity parameters

___
Fusioninventory-devel mailing list
Fusioninventory-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel