On Wednesday, October 16, 2002, at 10:00 AM, Puneet Kishor wrote: > yes, I know. That's why I wrote the above... hoping I would get a > response from you. ;-). Thanks for the response.
And I fell for it! Damn! > I am wondering if you folks have considered making some of the > complicated pieces optional... for example, "use mod_perl because it > will perform better, however, it will also work without mod_perl" > kinda philosophy. No. Bricolage is an enterprise application, not really designed for small jobs (though it can do them). The entire interface, for example, is written in HTML::Mason and requires Apache::Request. Without that, we'd need to completely rewrite the UI to use some other framework (Cocoa, anyone? ;-)). The target user for Bricolage is a magazine publisher or a newspaper. It's not really designed for hobbyist web site maintainers or bloggers. > I have also looked longingly at PostGres, but the reality seems to be > that MySQL simply has waaaay more momentum behind it. The same seems > to be happening with PHP. Something like MoveableType has the ability > to stem the tide because MT also functions at several levels... what > clinches the deal is the MT is just so easy to pick up and run with. > The same is with MySQL. More users using it means there is more > development, there are more tools to manage it, etc. etc. No, it doesn't. PostgreSQL is developing *very* fast, and has been ACID-compliant for years. It really is the only OSS database good for very large-scale applications like Bricolage. As for Moveable Type, it does much less than Bricolage does, and thus has far less demanding database requirements (hence its ability to run on DB_File). > Btw, I am not sure what you mean by "port Bricolage to MySQL." > Wouldn't that just involve setting up the tables in MySQL and pointing > the perl scripts to the new datasource? That should be really easy... > I think. Unless, you guys have tied Bricolage integrally to PostGres's > internal plumbing. There are a few ties, but not many. The issue is more that there is a *lot* of SQL in Bricolage, and unexpected issues could crop up. There is a DBD adapter framework built in to Bricolage, and an old driver for Oracle that could be updated fairly easily. MySQL would be trickier, but probably take an experienced SQL jockey a few weeks to port. There is only one storied procedure that I'm aware of. Patches welcome. > Please. I would love that. Please set up an account for me because I > am darned curious about bricolage. Give me a day or two to get that installation upgraded and configured. It seems to be down at the moment (I haven't had anyone ask for access in a while). > Also, if you set up a live demo with faux data in it that wouldn't be > a security risk, would it? After all, there would be nothing valuable > for folks to steal! It's more an issue with using Perl to access the file system than anything else. Bricolage is not really designed for open, public use. It's more of an application than a web site. Doing what you ask would take a lot of work, and I currently don't have the tuits. > Fwiw, please consider making it as easy as MT... a lot more folks will > use it, and it will just insure that it grows. I couldn't make it easier without removing functionality, and that in itself would be difficult. Bricolage does far more than any other OSS CMS/publishing system that I'm aware of. We're talking 110K+ lines of code here! But it *is* easy to install. Use a RedHat distribution with a good installation of Apache/mod_perl and PostgreSQL from RPMs, or use FreeBSD and its ports collection, and then Bricolage's own installer will take care of the rest. It's really not difficult. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
