On Fri, Aug 27, 2004 at 03:45:30PM -0500, Larry Kubin wrote: > Hello everyone. I am interested in creating a PHP/SQLite powered > bulletin board system similar to phpBB. However, I have read that
In that case, please pay careful attention to the features and UI of the OpenACS Forums package. It does have its flaws and lacks, but it's the only web-based bulletin board software I've ever personally used that doesn't suck. (There may be other non-sucky bulletin board apps, but I've never used seen or used them.) E.g., this old-ish running instance: http://openacs.org/forums/ Or here's a related code-base (OpenACS 3.x actually, very old) with a different look and feel - but very similar functionality: http://www.carnageblender.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000Cnt One flaw with those particular versions of OpenACS Forums is that they only allows two types of input, "plain text" and HTML. Other OpenACS applications offer a pallete of 3 or 4 standard textual input types: Plain text, HTML, Preformatted Text, and simplified HTML markup. Those various input options can be VERY useful for certain classes of users and types of discussions. If you want to read some anecdotes from someone else who implemented a web-based bulletin board (long, long ago), check out "Case 4: The Bulletin Board", here: http://philip.greenspun.com/panda/case-studies > SQLite is best suited for applications that are mainly read-only > (because it locks the database during writes). Do you think a SQLite > powered bulletin board is a bad idea? How would I go about handling Well, yes. But only because I think Yet Another stand-alone PHP bulletin board package is probably a bad idea; nothing to do with SQLite. > the case where two users are trying to write to the database > simultaneously? SQLite has limited write concurrency, but my guess is that the average website running some bulletin board software will never even come close to getting enough concurrent user submissions going at once to cause much trouble due to writes. SQLite will (unnecessarily) serialize them all (while PostgreSQL or Oracle would not), but that should be fine, for most sites. You MIGHT however have a VERY large number of peak concurrent readers (Slashdot Effect), so you should think about how to best use SQLite to insure that a small number of writers can't starve your thousands of readers. That should be doable, one way or another. E.g., one simple (not necessarily the best) way might be to simply cache the highest-hit pages in memory, and only update the cache at most once every 4 seconds or so. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
