[cgi-wiki-dev] Convergence with Kwiki?
Sun, 14 Sep 2003 12:46:57 -0400
One of the most notable things you had said to me, Peter, was that Ward
Cunningham had given his support to Kwiki. Coupled with Kwiki's =
broader adoption by Perl Mongers, Kwiki must be doing something right.
One thing I will reiterate is that CGI::Wiki::Simple appears crucial for =
no-brainer install yet that is relatively hard to find.
Lastly, with respect to the conversation about the name 'CGI::Wiki', =
it should be marketed as 'Wiki Toolkit' or similar?
Martin@Cleaver.org - +1 416 832 7759=20
Melbourne Business School FT 2004 MBA Exchange Participant to Rotman
=3DFrom: firstname.lastname@example.org =
=3DBehalf Of Peter Masiar
=3DSent: Sunday, 14 September 2003 11:42 AM
=3DTo: email@example.com; Tom Insam
=3DSubject: Re: [cgi-wiki-dev] Convergence with Kwiki?
=3DQuoting Tom Insam <firstname.lastname@example.org>:
=3D> At 0:34 -0400 2003/09/14, <Martin@Cleaver.org> wrote:
=3D> >Hi Kake,
=3D> >More questions: has anyone proposed, and what's
=3D> >the general feeling about, merging the efforts
=3D> >of CGI::Wiki and Kwiki? I question the need for
=3D> >independent efforts and wonder whether a joint
=3D> >community would have better economies of scale.
=3D> > Martin
=3D> Apart form Jonathan's point, for me the main
=3D> difference is that Kwiki is a bit of CGI that
=3D> implements a Wiki. CGI::Wiki isn't, it's a
=3D> toolkit that lets you build a wiki. There's an
=3D> important difference - to change how Kwiki works,
=3D> you're removing bits of it and doing your own
=3D> thing. You don't need to change how a CGI::Wiki
=3D> engine works, hopefully, it's just a matter of
=3D> building the front end differently.
=3DI am not sure I fully understand what do you mean by the way you =
=3Dhow Kwiki works.
=3DAFAIK (and IANAOOguru) Kwiki uses TT2 and other CPAN modules.
=3DIn many discussions in IRC ingy mentioned his Kwiki will not be
=3Da "product" wiki, but a framework to build multiple sets of
=3D(possibly incompatible) kwiki distrubutions (Kwiki calls them =
=3Dusing different sets of templates and plugins, with vastly different
=3Dfunctionality. IRC logs are available on Kwiki.org site.
=3DI do not know how functionality ingy promises will work and
=3Dif it is even possible, but ingy is working full time on Kwiki
=3D(paid by Social Software),
=3Dand looks like he has a lot of support from other developers.
=3DI.e. one guy works on database-bases storage system (a plugin),
=3Dalso L10N (Localization) is in Kwiki core,
=3D http://www.kwiki.org/index.cgi?KwikiLocalization by author on CPAN
=3Dmodule for it.
=3DI would like to see Kwiki as CGI::Application based wiki,
=3Das I understand CGI::Wiki is C::A based (correct me if I am wrong).
=3DI try to monitor both Kwiki and CGI::Wiki, and, like Martin Cleaver,
=3Dam interested how feasible is for both projects be integrated.
=3D> Of course, having said that, I _did_ write
=3D> CGI::Wiki::Kwiki, which was intended to be a
=3D> simple Kwiki-like front end to CGI::Wiki that
=3D> Just Worked, but that was more of a 'move your
=3D> kwiki to a 'real' database' aid than anything
=3DI currently use Twiki and I like text file storage - for me
=3Dit is prefereable to database. Are you saying that
=3DCGI::Wiki has only database storage? I see requiring DB
=3Das possible red flag for small wikis and unnecesary
=3Dinstallation hassle (although maybe important to get
=3Dwiki work under heavy load). IMHO there will be huge market
=3Dwhere simplicity of file-based wiki will be more important
=3D - and as I said Kwiki could have DB backend too in couple of months.
=3D> There's no way that openguides could have been
=3D> built on a Kwiki without serious messing around.
=3D> Openguides is obviously a wiki, but not what I'd
=3D> think of as a 'traditional' wiki...
=3DIIUC, CGI::Wiki is build first to be a wiki engine for openguides,
=3Dand only after that as a wiki framework - and for wikis with
=3Ddatabase backend only.
=3DKwiki is being build as many different wiki clones now,
=3Done of them is openforge (OF) - a perl-based sourceforge clone.
=3DUnlike sourceforge and GPL GForge, which are PHP-based,
=3Dopenforge is pure perl, uses SVN (subversion) and CVS,
=3Dand integrates RT bug tracking system (and being developed
=3Din Taiwan, is localized in the core).
=3DKwiki is expected to be a wiki for this project hosting
=3Dsystem. Unlike sourceforge, you will not host your project on OF,
=3Dbut install your own OpenForge, setup and manage it as *you* need.
=3DI understand that my preferences are affected by Twiki and they might
=3Dnot be for everybody, and openguides might have very good
=3Dreasons to do what you do. But in some responses there was some
=3Dmisunderstanding (AFAICT) about Kwiki (and I am not an
=3DKwiki expert either :-) ) which I want if not explain, at least
=3Dkeep open for research and discussion by real experts.
=3DI currently use Twiki, but (for reasons mentioned by Martin earlier)
=3Dwant to move to a better wiki engine. As you can tell, currently
=3DI am more inclined to Kwiki :-) - but I did not decided yet.
=3DBTW new version 0.18 of Kwiki
=3Dwas just released and I'll be *really grateful* if somebody can
=3Dpoint out where I am wrong and misleading myself :-)