All the Perl that's Practical to Extract and Report

My Kind of Kwiki

mako132 on 2003-06-18T13:43:48

I've recently moved my personal Wiki from UseMod Wiki to CGI::Kwiki. Both are easy to install, but CGI::Kwiki makes it easy to install multiple Wikis. For example I have a test Wiki where I can monkey around with things. It was as easy as,

cd cgi-bin mkdir test cd test kwiki-install

The biggest selling point for me was extensibility of the software and that the data is just text files -- no database, no gdbm, no funky semi-text, no XML. Just fine for personal stuff, debatable if you're considering using it for the enterprise.

So now I run two copies -- one on my office Linux system, reachable over the internet, and a local copy on my Mac OS X laptop. I keep the two in sync by rsync-ing every 15 minutes between 9 AM - 6 PM via a cron job on the laptop. When I have net access, I'm hitting my Linux system, when I don't, I'm plugging away on my local apache on the laptop.

SQLite

koschei on 2003-06-18T14:08:21

I've been meaning to plug SQLite in, to see how well it works as a db backend to Kwiki. Can't think of how to handle revisions though, since I do want the versioning, and ideally not by storing complete copies.

No doubt I'll think of something eventually =)

But, it would be nice since it would remove any dependency on having wikiwords conforming to filesystem naming rules.

Re:SQLite

dlc on 2003-06-18T20:38:27

I hear SQLite has problems with concurrent access.

Re:SQLite

ziggy on 2003-06-20T16:22:23

It has a problem with concurrent access while writing. SQLite can handle multiple readers with aplomb. But it locks the entire database when there's a write transaction in progress.