If this project is as large as you make out then the platform for it is not really an issue. Whether you use MySQL, PostGres or SQLServer (amongst others) you will want them on their own machine and connect to them via the DBI and the relevant DBD driver (ODBC, PG etc).

I totally agree with you on that for large sites, but the system must easily support small sites as well as large. In other words, we need to have an install plan, that will work nicely on a small server, as well as for large clusters, where we offcourse as you suggest, will have dedicated database servers. Another issue for some of our smaller customers, is cost, some of the larger DBMS's can have a pretty hefty price tag. Therefor, the system should work with both a small preferably free DBMS, as well as a large commercial DBMS on a dedicated server.

As for a scripting language - why not use Perl itself? You can quickly define a set of macros and comeup with an application object that presents a partcular API. Its then trivial to check for bad code, to untaint and to run the app.

...would be pretty cool from a programmers point of view =). I did give it a few thoughts earlier, but dismissed it as beeing to hard for non programmers to learn.... aaand, I wasn't sure how to go about with the "bad code" checking... anybody have any pointers to some information about that? similar projects or something like that?

thanks for your reply! it gave some good food for further thoughts...
Kasper

I was part of a project that, among many other things, created our own scripting language. It was extremely basic, using \n to indicate the end of a statement and implemented only SET/JMP/JZ/JNZ/IF/ELSE/ENDIF/WHILE/FOR/RETURN. That was it.

Now, this wasn't OO. However, what concerns me is that you want to create an OO language and expect non-programmers to be able to handle it. That's got "Bad Plan"(tm) written all over it. Perl is the easiest "real" language to learn, except for VB. (Maybe that's why M$oft made VB their scripting language of choice?) Start small. If you're smart in your design, the language should be upgradeable without impacting anything else. (Maybe a Script::* set of modules?) Plus, demanding that your users actually understand the basics of procedural programming isn't unreasonable - it's almost expected, these days. If your users demand scripting capabilities, you can demand knowledge. (Unless, of course, you were planning on writing a GUI "editor" that allowed them to drag-and-drop statements from a list... if you're doing that, quit your job and write a game.)

As for bad code checking, use eval. Let the interpreter check bad code for you! Oh, you can do basic easy stuff, like balance parentheses and the like, but don't do any complicated syntax or nothing. Why kill yourself when Perl does it already??

As a small database on small system:
Do you mean simple PC? I run MS Access with 3GB database, and it survived. MS Access is "free": bundled in MS Office pro, you have MS Office anyway, right? You can access Access database (MS Jet Engine) via ODBC and DBI just fine. Your SQL will be multi-platform as long as you will use only standard SQL and avoid any proprietary extensions - but DBI will wisely guide you to use standard SQL only ;)

pmas
To make errors is human. But to make million errors per second, you need a computer.

Mod_perl is most likely something you want to investigate for your VM.

good luck
gwhite

Update: Fixed the cygwin link