[gcompris-devel] Log Module for gcompris

[stasZ]

On 2004.01.19 02:55, Bruno Coudoin wrote:

> That's a good oportunity to think about what we need here (stasZ,
> still
> there ?).

Yep,
 
> With you code, we monitor the time in each board/level. That's a good
> start but to be usefull, we need some sucess/failure data and a
> comment
> on what failed so that a teacher can easily read it.

I paste a bit of a earlier discussion between Bruno C and me, because i
believe the solution is still the same :-)

the ">" pieces are from Bruno, the rest are my former replies:

####### Begin old discussion ################

> First, we can easily include in gcompris a call to a sucess/fail
> recording based on the bonus API. The bonus API is the one a board
> call
> when it's a done or a fail. This means, we don't need to change all
> the
> boards to do this, just improve the current bonus system.

You should also consider to put the "raw" result in a XML format
in a temp file ,which should be cleared at exit, so that there's always
a possibility for users/teachers to handle the results with there own  
tools.

> Then on the end user level we need to be abble to access to the
> classroom result. A web interface could be fine but its should also
> work
> in a 'parent' environment in which a web interface could be too heavy
> to
> set up.

I think its better to send the results by email to avoid all kinds of  
security
issues with web servers. Again if the result/report is in
XML/openoffice format then it could be send as a attachment to any  
place on
this world and handled by any application.
Internally it could also be put in plain text and pasted in the mail  
body.

> The interface should answer to the question who did what and when in
> gcompris.
> 
> The system we propose should be independant of gcompris. We should be
> able to propose kdeedu, childsplay, the python games developpers, and
> other free school developpers to leverage and integrate it in their
> own
> software (I copying the most active developpers I know)

That's the future (IMHO), it should be as platform independant as  
possible.
Also as speed is not a issue, because only when the user logs out/stops  
the
tool gets a standarized list/file to handle, so it could perhaps be a  
stand
alone apllication.

> We are facing a problem with login. In some environment, we don't  
> have
> a
> login per user. It could be necessary to create in gcompris a pseudo
> login (profile) to record the user name.

The childsplay monitor plugin handles users login and  sets permissions
based on a rc file, also there's a possibility to put users in groups.
(the whole idea is based on Linux permissions)

The monitor plugin also handles the actual login stuff and ask for a  
name and
let the child choose a nice icon to create a "name-badge"
which could be printed out (in the future:-)
The presents of the monitor plugin changes the workings childsplay, by
giving control to the monitor (when needed).

> That's all I have think of. Feel free to discuss the what and how to
> do
> this on this list so that Bruno Patin will get most of the  
> requirement
> early in the development. If anybody want to join, it's would be
> great,
> there is definitly room for others.
>

Well, apart from the Gcompris side of things i"ll suggest we combine  
our
efforts at much as possible, so hereby i sign up :-)



--
"There are only 10 types of people in this world:
 Those who understand binary, and those who don't."