Yop,
- Backward-compatible API
I think we can do it. No major API break was done during the whole development, and I think we can continue in that way, thanks the simple "linear" API style (opposing to object oriented API). Another possible option, if we absolutely need to break backward compatibility in the future, is to change project's major version (ex: Raydium 2).
- Full API (ODE + PHP + RegAPI)
Yeah, why not. When I started to work on ODE and PHP, my main idea was to provide theses features as options. I must admit that RayODE and RayPHP became quickly mandatory in my mind :) The only (small) benefit right now is a quicker compilation with small "no-ODE and non-PHP" projects like raydium_modler, so I think we can definitely consider theses API as core ones. (starting with removing *PHP_SUPPORT, *ODE_SUPPORT, ... in config.h)
- NuSOAP
A few months ago, Prospere decided to change the way ManiaDrive was "talking" to website and database, switching from simple HTTP requests to WebServices. As I was wanting to integrate this great change quickly, and since we're always stuck with PHP4 wich is not providing native support for SOAP (unlike PHP5), we decided to temporarily merge NuSOAP to SVN repos. No doubt for me, the good solution here is to switch to PHP5 :)
- raydium.db in user "home" directory
Again, why not. The main problem I see here is that we must support Linux and every windows version. Need some research, for me.
- Makefiles instead of compilation script ?
OK for me, but I
want to be able to make a compile+run cycle in one line :)
I like *comp* scripts, since it allows me to open and power-up my laptop anytime, anywhere, logon and enter someting like
./ocomp.sh myapp.c and start working with/on Raydium VERY quickly. Create a new Makefile and do multiples
make raydium;make myapp each time I want to test something is not why I call "simple" :)
Perhaps can we provide a better and more powerful version of Makefile, but still offer *comp* scripts. Note that a rewrite of theses scripts is planned since a looooong time to centralize GCC options in one configuration file (or a '...-config' command, see below) instead of duplicate it in every script like it's done for now. Feel free to work on Makefile ! (I think you can contact Mildred if needed, wich wrote the [great] original Makefile)
We must also think about the best way to allow people to link their apps to Raydium using their own building system, perhaps with a 'libraydium-config' binary (like 'libpng-config', for example). This last idea is perhaps the best way to unify Makefile and all *comp* scripts.
- per-app directory in SVN
I think that you can imagine how huge is a such change :) Appart from the "technical" work needed for this new organisation, I'm used to work with "one-big-dir" (c) for years now, and it will be hard to change the way I work :)
BUT, you're right. It's hard to say, but you're right :) The only real problem I see with splitting apps like this, is data redundancy: Raydium applications shares a lot of files each other... That's one of the main ideas behind CQFD data repository: providing a "big" common database of models, textures and sounds for various Raydium apps.
For example:
Code:
[xfennec@Julien opengl]$ du -sh
2,4G .
... I can't waste more drive space because of duplicated data ;)
IMHO, we must find a way to allow different apps to share data (even if it works only with the default SVN directory structure) and write a new "full" Makefile before starting project tree reorganization.
Don't you think ?