Hi Zoltan,

the self implemented Wiki is one of my most annoying problems in daily work, too.

I did some researches the last years for wiki systems and ended up with Foswiki.
Thus I'm still looking for a solution to bring Foswiki & ChiliProject together -
with my experiences in Perl it should be possible to develop a Foswiki + CP plugin for that.

But:
I'm afraid that there are many parts of the CP sources, which strictly / directly
rely on the internal Wiki - which would be a big pity.

But nevertheless: As experienced developer I share your opinions regarding modular
software architecture and reusing existing code as often as possible. In comparable
projects I noticed that many developers thought "Implementing feature X by myself
is much faster than learning how to use an existing solution".

My daily job is exactly solving/preventing such pitfalls by motivating my staff
to invest time to analyze and integrate third party solutions instead of reinventing
the wheel.

It should be clear that such a big architectural switch isn't feasable in short time -
but how about starting with a plugin based integration of a third party Wiki as a
first step? That would be a good point for me to start contributing - especially because
I could realize that in my work time or by one of my colleagues.

ciao,
Chris

Zoltan, that's also one of our main pain points with the current codebase, ripping out the wiki won't be easy though, as a lot of stuff relies on the wiki syntax.

Our way forward will probably be though: get up to current rails versions, rip out stuff that is not strictly part of the "project management" part of ChiliProject and make modules/plugins out of them, if applicable still in the ChiliProject organization but not in the main codebase (prime example: the SCM adapters, currently we only have people knowledgeable with svn and git, so we could make those official plugins, the others will need to be taken care of by other people).

Zoltan, would you be interested in helping out? Even without Ruby knowledge there's other things that we need help with :-)

@Chris Dähn:

I know what "restructuring the core" means -> collapsing the top (depend on the degree of layering) typically it's an all in one breath long puzzle game with weak loopback (except, it's based on strict system design)

by the way, will be interesting to find a long-term reliable information bridge from CP to Tiki/Fos, the rest is up to this.

hm, http://tiki.org/Tiki+vs+Foswiki the Foswiki's 8M LOC is convincing against Tiki's 1.4M but Foswiki's commits slowly decreasing https://www.ohloh.net/p/Foswiki, https://www.ohloh.net/p/tikiwiki (or maybe foswiki reached a high degree of product maturity)

@Felix Schäfer:
Ok, i knocking on open door.

Felix, thank you for the invitation, at this moment i'm could only be a User.
(time lack)

One more thing, take a look at this site: http://bitnami.org/contest, i pushed CP to the first page, maybe this community could push it to the first place, in all meanings ;)
(RoR setup is a pain in the ... on Windows platform. Good sign there is a great tut. at this forum.)

Zoltan Berge wrote:

Ok, i knocking on open door.

Indeed, but it's good to know other people think alike :-) I have finished a couple blog posts yesterday, the first should go up today.

One more thing, take a look at this site: http://bitnami.org/contest, i pushed CP to the first page, maybe this community could push it to the first place, in all meanings ;)
(RoR setup is a pain in the ... on Windows platform. Good sign there is a great tut. at this forum.)

We actually provide a way to create your own VM with much of the stuff needed for a full ChiliProject install, have a look at https://github.com/chiliproject/vagrant/

@Zoltan:
Foswiki runs with currently the smallest footprint (memory+cpu) of the wikis I saw so far, is mature since the fork of twiki and has numerous plugins and extensions. For me the security issues of PHP and the lack of some plugins was a reason to decide against some wikis (including Tiki). But I think all these wikis do their job quite well - so it's a question of taste ;)

@Felix:
I appreciate the new Vagrant solution! But: I saw a user still has to face the problems with the bundler - getting this running was my hardest task during the installation - especially on Debian Squeeze systems. So we still need a solution to set up the prerequisites for Vagrant, right? Could this be solved by an installer script?

In the meantime I could setup an openVZ / KVM virtual machine for CP - if needed, I can provide some virtual machines of my servers / root access to them (e.g. for testing and as demo machines).

Chris Dähn wrote:

I appreciate the new Vagrant solution! But: I saw a user still has to face the problems with the bundler - getting this running was my hardest task during the installation - especially on Debian Squeeze systems. So we still need a solution to set up the prerequisites for Vagrant, right? Could this be solved by an installer script?

To be honest there's somewhere we have to draw a line or we'll end up providing CDs to install an OS to install ChiliProject or whatever. I think getting vagrant up on squeeze is a common enough task that there are tutorials out there for that.

Bottom line: we'll happily feature it and add it to our preferred install options if someone makes a script, but we won't write and/or support one because we're short on time as it is already.

The install script will cause big work, that's right. But it should be feasable - e.g. by a contributor :-)

So if we reduce the platforms to only the mostly demanded ones (e.g. Debian, RedHat/CentOS, Ubuntu) I could imagine to build and maintain such a script - and additionally provide openVZ containers for that. I already discussed that with my colleagues...

Ok, then I've a plan: Develop a script to install (and maybe start) Vagrant.

I'll start with Debian. The question of which other platforms are needed should be cleared by a poll or a discussion here...

Maybe on the new landing page? ;-) (I'm currently setting up a mockup for it)