Quoting Tom Insam tom@jerakeen.org:
At 0:34 -0400 2003/09/14, Martin@Cleaver.org wrote:
Hi Kake, More questions: has anyone proposed, and what's the general feeling about, merging the efforts of CGI::Wiki and Kwiki? I question the need for independent efforts and wonder whether a joint community would have better economies of scale. Cheers, Martin
Apart form Jonathan's point, for me the main difference is that Kwiki is a bit of CGI that implements a Wiki. CGI::Wiki isn't, it's a toolkit that lets you build a wiki. There's an important difference - to change how Kwiki works, you're removing bits of it and doing your own thing. You don't need to change how a CGI::Wiki engine works, hopefully, it's just a matter of building the front end differently.
I am not sure I fully understand what do you mean by the way you describe how Kwiki works. AFAIK (and IANAOOguru) Kwiki uses TT2 and other CPAN modules. In many discussions in IRC ingy mentioned his Kwiki will not be a "product" wiki, but a framework to build multiple sets of (possibly incompatible) kwiki distrubutions (Kwiki calls them "flavors") using different sets of templates and plugins, with vastly different functionality. IRC logs are available on Kwiki.org site.
I do not know how functionality ingy promises will work and if it is even possible, but ingy is working full time on Kwiki (paid by Social Software), and looks like he has a lot of support from other developers.
I.e. one guy works on database-bases storage system (a plugin), also L10N (Localization) is in Kwiki core, http://www.kwiki.org/index.cgi?KwikiLocalization by author on CPAN module for it.
I would like to see Kwiki as CGI::Application based wiki, as I understand CGI::Wiki is C::A based (correct me if I am wrong).
I try to monitor both Kwiki and CGI::Wiki, and, like Martin Cleaver, am interested how feasible is for both projects be integrated.
Of course, having said that, I _did_ write CGI::Wiki::Kwiki, which was intended to be a simple Kwiki-like front end to CGI::Wiki that Just Worked, but that was more of a 'move your kwiki to a 'real' database' aid than anything else.
I currently use Twiki and I like text file storage - for me it is prefereable to database. Are you saying that CGI::Wiki has only database storage? I see requiring DB as possible red flag for small wikis and unnecesary installation hassle (although maybe important to get wiki work under heavy load). IMHO there will be huge market where simplicity of file-based wiki will be more important - and as I said Kwiki could have DB backend too in couple of months.
There's no way that openguides could have been built on a Kwiki without serious messing around. Openguides is obviously a wiki, but not what I'd think of as a 'traditional' wiki...
IIUC, CGI::Wiki is build first to be a wiki engine for openguides, and only after that as a wiki framework - and for wikis with database backend only.
Kwiki is being build as many different wiki clones now, one of them is openforge (OF) - a perl-based sourceforge clone.
Unlike sourceforge and GPL GForge, which are PHP-based, openforge is pure perl, uses SVN (subversion) and CVS, and integrates RT bug tracking system (and being developed in Taiwan, is localized in the core). Kwiki is expected to be a wiki for this project hosting system. Unlike sourceforge, you will not host your project on OF, but install your own OpenForge, setup and manage it as *you* need.
I understand that my preferences are affected by Twiki and they might not be for everybody, and openguides might have very good reasons to do what you do. But in some responses there was some misunderstanding (AFAICT) about Kwiki (and I am not an Kwiki expert either :-) ) which I want if not explain, at least keep open for research and discussion by real experts.
I currently use Twiki, but (for reasons mentioned by Martin earlier) want to move to a better wiki engine. As you can tell, currently I am more inclined to Kwiki :-) - but I did not decided yet.
BTW new version 0.18 of Kwiki was just released and I'll be *really grateful* if somebody can point out where I am wrong and misleading myself :-)
Peter Masiar