[cobalt-developers] Peer review needed: Message board

["Matthew Nuzum" <cobalt@xxxxxxxxxxxxx>]

I'm working on a message board script that works much like the neo-mail
package.  It can be installed once on a Raq server and it would be available
for all of the sites.  I'd like some input as to how I implement a few
features.  Here's my plan:

- Installing the PKG file creates a folder where the shared message board
files go.
- A virtual URL is created.  neomail is called /webmail, which is nice and
simple.  I'd like one that is similar, but I don't want to conflict with
people who already have a message board, any suggestions?  For this example,
I'll use bboard.
- First time a person goes to http://<SITENAME>/bboard a folder is created
in site-root that contains the images, database files, header.html,
footer.html (should we allow php here?) and a simple config file.
- Config file is plain text, VARIABLE:VALUE type file.  No PHP, so there can
be no malicious code or looking at other people's database.  Default values
will provide a fully functional board, but changing them will allow better
integration with the site.
- A username/password is specified in the config file that allows moderation
of posts.

So here are my specific concerns:
What do you think of the virtual URL, http://<sitename>/bboard?  Any
concerns or suggestions?

What do you think of the idea of creating a folder in the site root called
/bboard that contains files that can be customized?  I thought it would be
nice to put the database files in there so that they can use up the site's
storage space.  The alternative is to store all database files in a central
place.  Actually, as I write this, I may have difficulty creating a folder
in the site root, due to permissions.  The webserver doesn't have write
permission on the site-root, does it?

What do you think of the ability to allow PHP code in the header and footer
of the page?  Probably a bad idea isn't it?  Maybe a config option can be
put in that allows that feature to be selected.  Some server admins may want
it, others may not.  That's probably the way to do it, and by default, have
it turned off.

Any other concerns or gotchas to suggest?

Thanks for your help,
Matt