Re: [gcompris-devel] Re: [seul-edu] Reflexions on a KDE-Edu program

[Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.ac.be>]

On 8 Apr 2002, Bruno Coudoin wrote:

[...]
> > In this context, do you have any plans to move to CORBA or Bonobo
> > components in the future?
> 
> I though to use this kind of technology one year ago but it was not
> mature enough at that time. The drawback with these technology is that
> it is complex to set up and develop with.

That depends: if some core functionality for including components is
developed by the key people, new contributions should have less
problems adding their stuff. But CORBA _is_ a significant threshold to
take...

> If we want more people involved on a project, we need to keep then entry
> barrier low. Today, C knowledge and the gnome canvas is all you need to
> know to create a new board in gcompris.

Well, one ends up now with a lot of C code that is always that little
bit different, and quite significantly tied to the gnome environement,
such that it is difficult to maintain in the long run, or to embed in
itself in another package.

> Now, I am not sure corba or bonobo would bring much to this project. Do
> you have somthing in mind?

No particular things, no. I was just wondering about whether there was
a long-term strategy in this respect. For our own work on robot
control software, we did decide to go the CORBA way. So I know now
that that decision involves some effort indeed :-)

But even without CORBA, it would be useful to describe the interface
between GCompris and plugins _exactly_ and _exhaustively_, in both
directions. Your documentation about new boards has already most of
these things, of course. But CORBA would add programming language
independence. This has disadvantages too, of course: it's tough to
distribute a package in which some parts are in C, others in C++, and
still others in Java...

[...]
> This WE, I found ggz (http://ggz.sourceforge.net/)
> I wonder if we could benefit from a such infrastrure for the grading
> system but also user monitoring and help (chat is already in ggz). Also,
> why not creating boards that can be played in group. It could create
> group emulation to complete the multiplication table the fastest for
> exemple, or dedicated board that are multiplayer oriented.

These are good ideas :-) And I guess distributed grading systems are
about to pop up everywhere... Probably without much mutual
compatibility, unfortunately.

Herman