well as im not sure which your talking about, i'll discuss both:
1) perl stored in the DB - this would be doable with a small amount of effort, by subclassing the parser and extending it to query the DB instead of looking on the filesystem.
2) making table entries to represent conditions and actions to be preformed by quests - This option is significantly more complicated to implement, and even then it would not provide near the flexibility of using a scripting language. Sure, 90% of quests are simple hails or handins, but as soon as it gets much more complicated than that, representing it accurately in the DB gets exponetially more difficult.
The best solution to manage collaborative quest work is to use a source code control system such as cvs or subversion... give your quest people commit access, and you can pull them from CVS down into your server... and even audit the changes if you want.
|