[gcompris-devel] Log Module for gcompris

[Bruno Coudoin]

OK, let's start. I propose the following format for the trace.

Trace formating
date,computer,user,board,level,sublevel,status, duration,comment
status can be : DONE or FAILED
comment is a free optional string that can describe what went wrong. For
example, in a reading activity, you could write here the word that make
the kid fail. It may be usefull for the teacher.

Ralf, I did not followed excatly your proposal. It's more ready to be
useable I think if we don't save start and stop events by only DONE or
FAILED.

I will add this feature in gcompris core so that we can have a trace
gcompris wide real fast I hope.

Comments welcome.

Bruno.


Le lun 19/01/2004 à 09:07, stasZ a écrit :
> 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."
>  
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> gcompris-devel mailing list
> gcompris-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gcompris-devel
>