Proposal T4GF - TWiki for GForge

I was looking for a open-source system to handle other needs of IT infrastructure for department working on many small-to-medium software projects) and found GForge, http://gforge.org/. It is an OpenSource derivative of the SourceForge code, and an excellent tool for departments and small software companies to manage projects. It has CVS, ViewCVS, bug tracking, maillist, forums, project management, jabber IM server etc.

The only thing they are missing is a wiki for docs, and they started looking for one.

Most obvious candidate for them will be TikiWiki or PHPwiki (because GForge is in PHP), but these wikis lack Twiki's features. But the perception is, although twiki is most poverfull and has multiple webs for multiple projects, as GForge needs, Twiki is too hard to install.

But Twiki community developed most of the ingrediences needed:

• MichaelSparks has TWikiUnixInstaller
• There are many decent skins
• CommentPlugin lowers barrier for contribution to zero
• SmartSessionPlugin could integrate login with GForge seamlessly

Twiki has more developers than CoreTeam can accomodate in stable branch. Why not let them to work on the FriendlyFork for GForge? SoapClientPluginSoapClientPlugin

And we cannot wait another 3 months to decide this - I am sure TikiWiki will be glad to be default wiki for GForge and for hundreds of projects, and I bet they are working to make it happen. Maybe it is already too late - but it is worth the try, IMHO.

If integration Twiki and GForge is interesting to you - please raise your voice now! Add arguments pro and against - consider not signing them, but sign in the poll

FAQ

• How GForge is different from Sourceforge.net?
  • GForge is your own server like SF. Uses SF code and behaves like SF (and some better features), but is is your own server for your own group/department
• Do you want to move Twiki.org from sourceforge?
  • This initiative is about something different. If is about creating TWikiDistribution closely integrated with GForge (and to be default wiki for many hundreds of software projects.
• Are there are other projects like GForge?
  • SourceForge or GNU savanna it is not - they will host your project, GForge let you manage it. There is OpenForge, pre-alpha (fully perl) but they already have wiki, and guess what - it is a KwikiWiki.
• Will it be easy?
  • No: GForge is based on PHP and we need to work hard and be quick to make it before PHPwiki or TikiWiki. But we need to try, IMHO.

Arguments for integration

Imagine if group of non- CoreTeam developers created specialized TWikiDistribution, which would quickly implement changes GForge needs. Imagine how Twiki will be installed on dozens of servers with GForge, and hundreds of projects will use it as a wiki to write specs and help pages and track XP steps. Twiki will become instantly first and only wiki they need and ever used!

Arguments against integration

I am fully aware that these changes might will be incompatible with stable branch at first - but we can incorporate then into stable branch later, when changes stabilize. T4GF will test-drive these changes for core distro, if you like it more that way .

---

Poll

Do you want to integrate Twiki with GForge? You can vote "yes" also if you cannot participate, but would like if other developers who need it did it within Twiki)

Also you can vote "shup up" to tell me (us) that this in not appropriate in Twiki community.

Name	Integrate?	Participate?	Shup up	Comment
PeterMasiar	yes	yes	no	imagine future possibilities - Twiki everywhere
RandyKramer	yes	no	no	(almost) anything to increase user and developer base
SvenDowideit	yes	yes	mmm	As this is what i use the TWiki for at work, integration would be interesting
TorbenGB	yes	no	no	can't code, can't contribute. Sounds good to have another "sales channel" for twiki. Right now other things might take precedence though (and I realize that Gforge won't wait for us).
ColasNahaboo	yes	yes	no	Gforge seems good as it (seems to) use existing techs rather than reinventing everything. I would participate only if we decide to fully support it, i.e. reduce TWiki customizability to gain better debian-level automatic upgrades. Otherwise, maintaining the standard (too) flexible TWiki and its gforge version may be too much work. But in my opinion, everything that drives us towrads easier upgrades will be good, and the gforge integration may be this push we need.
PeterThoeny	yes	no(1)	no (why?)	Can be an interesting proof of concept for a TWikiDistribution. I support it and we can enhance the core code where the Plugin API is not sufficient. As always, (1) patches that are tested and follow the PatchGuidelines make it easy for the CoreTeam to bring in changes
AndreaSterbini	yes	no	no	It's a good way to push TWiki in new directions! (I am sorry that I have no time to devote to it, apart for working on the core/plugins)
JamesTillman	yes	yes	no	I've already incorporated TWiki into our own GForge environment, although a second login (same usercode/password as Gforge) is required to edit Wiki pages

(do not forget to release lock to allow next guy to vote, too )

Implementation

• see SoapClientPlugin for a way to access the GForgeSoapApi.

See also: TWikiDistributions

Discussions

GForge is based on PHP... How do you see this in relation to we can incorporate then into stable branch later ? I understand your enthousiasm for getting a wider audience, but this seems to be a very high practical hurdle. -- ArthurClemens - 08 Sep 2003

I do not know yet even if it is possible at all - AFAIK nobody has any idea what changes are required. Question is, are there people interested of researching this option (looks like yes), how many, what needs to be done, and if Twiki.org community is open enough to allow us to talk about it (I hope it is). Or is your vote, Arthur, for "shutup" -- PeterMasiar - 08 Sep 2003

No, please go ahead. But I don't see that part of "integrate" happen yet. -- ArthurClemens - 09 Sep 2003

---

GForge is interested in integration

GForge guys got interested in Twiki integration - and even want to put their own docs into a Twiki. For us it so obvious, but it was not for them . I'll like help from Twiki experts on LDAP about how to integrate GForge user management with Twiki. IANAexpert, IMHO best thing would be enhance SmartSessionPlugin.

-- PeterMasiar - 15 Sep 2003

This does look like an interesting project - didn't realise initially that GForge is a derivative of SourceForge code. Integration using SOAP sounds like a good option since there's already a SOAP API.

-- RichardDonkin - 15 Sep 2003

GForge guru asks:

• right management (to avoid multiply the user database): interact with postgresl or ldap database?
• keep the session between gforge and wiki , so a user logged on one side don't have to log again: how do wiki handle session?
• do we have to duplicate wiki code for all project virtual host ?or can we share part of the installed code between twiki

Are Twiki gurus interested? Does CoreTeam bless or wrath this integration?

-- PeterMasiar - 16 Sep 2003

Unless there's a particular CoreTeam member who wants to run this, I think this is best done as a FriendlyFork - as long as the changes are done in a modular way and with good code quality, the key parts of them could be filtered back into the core, but with most of the work staying in the FriendlyFork.

Some sort of customisation of TWikiAccessControl code and (probably) SmartSessionPlugin, to use Postgres or LDAP and integrate session management with the Gforge side, would be necessary. Ideally this could be done through extending the PluginAPI in the FriendlyFork, then putting these changes back into the core code - thereby improving TWiki's plugin API and also providing Gforge-specific plugins, so that ultimately the FriendlyFork turns into a TWikiDistribution. This is probably a good model for fairly compatible FriendlyForks generally (others may wish to comment!)

As for duplicating TWiki code for virtual hosts - this is not necessary as long as you use CGI. If the aim is to use ModPerl, see ModPerlize, which is making sure that many TWiki instances can run under mod_perl. There's quite a lot of mod_perl experience already but some work is necessary for very high volume servers.

-- RichardDonkin - 16 Sep 2003

mmm, didn't think we needed a FriendlyFork as most of the work should be able to be done using plugins and possibly a new backend module..

-- SvenDowideit - 19 Sep 2003

In the spirit of BewareTheQuietLeavers, I altered my MartinCleaver page a while back to state that I have little interest in participating in TWiki as is. Further, I simply can not be bothered updating the various initiatives I was focussing on, anyone interested can append 'lack of leadership and acknowledgement of key players' as a harsh - but in my eyes fair - lesson for TopicsThatDie.

However, TWikiFor anything - such as embedding into PhpNuke, PostNuke, CgiWiki or Kwiki - any means of subsuming TWiki's formatting capability into another project has potential as the right exit route for me. I'll consider what it would take, how much I am prepared to give and whether this would be sufficient over the next week.

If you would be interested in exploring or supporting the creation of RenderDotPm, in my view a first step, please write here or drop me a line. Your comments might make the difference of whether I drop my involvement altogether.

-- MartinCleaver - 20 Sep 2003

I'm not sure exactly how Martin's comments link to GForge. I think it's a good idea, but personally I can't give much time to help. TWiki remains a robust and powerful system. It may not be changing as much or in the ways that some people want; but it is still improving in functionality whilst remaining robust.

(I've removed the include on Martin's signature, I think there is broad agreement that this is not necessary or appropriate).

-- JohnTalintyre - 20 Sep 2003

Martin's comment seems to be off-topic. The Codev web is gaining momentum again after the confusion we had in summer, a positive trend everybody likes.

As for the GForge TWiki, I fully support it. I do not see this as a fork, why would that be a fork? If we follow the Linux model, the GForge TWiki can be one of the TWikiDistributions. Which makes it easy, since there is only little code merging needed if done right.

How:

• Move needed functionality as much as possible into a GForgePlugin
• Use and enhance existing Plugins as needed, like SoapClientPlugin, SessionPlugin, SpreadSheetPlugin etc.
• Enhance the core code where needed, preferrably on the Plugin API side.

-- PeterThoeny - 21 Sep 2003

I don't know if it's useful, but I am back-porting a AuthCookieHandlerPluginDev (the name will change) from a project of my friend FrancoBagnoli . The plugin stores authorization settings in a Mysql (I am using DBI ... it should be easy to port it to Postgres) database that is used by two authentication handlers for Apache/ModPerl .

The nice thing is that now I can protect the pub dir and even use WebDAV to edit attachments.

-- AndreaSterbini - 21 Sep 2003

Hi, more and more people are Interested in twiki integration, so let's go on. I need some advices to start.

I plan a very basic twiki integration at the begining.

The first idea is to provide a per gforge project twiki space

So,

• should I install one twiki for all project (e.g. a customized debian twiki package)
• or create a twiki per project, duplicating twiki code for each project.

I would prefer the first solution, but i don't want to be be to constrained by the choice.

I would like to keep the gforge user management, where right are controled by each project admin, in a unified place.

It should be also possible to allow anonymous writing

I would like to be able to make private a wiki

I imagine that the finest way to transmit right would be that twiki get all this info in the gforge ldap db or directly accessing to the gforge postgress db.

• ldap solution seems better for me since it's more standart way to propagate rights, but
• postgress on the other way could be easier to use, since all gforge install don't use ldap.

Ideally it would be nice to have the two solutions

One point in favour of one twiki would be to be able to have either a twiki view of projects or a gforge view.

It should probably be possible to create a gforge project by twiki interface as easily as a twiki space with gforge.

Your thoughts, thanks

-- ChristianBayle - 06 Nov 2003

Both approaches have advantages... Since GForge has no web development tools I am guessing a lot of people would like to use TWiki for development of webpages on project and would therefore prefer a higher level of customisation in design. On the other hand it makes sence to have tight integration with existing GForge design so that TWiki acts like extra service rather than application installed onto another one.

Some work on automatic TWiki setup/backup was done by Toni Prug (tool is "stac" and project was www.OpenMute.org)... maybe he should be contacted?

-- ZeljkoBlace - 11 Nov 2003

Solution: trac

http://projects.edgewall.com/trac/about_trac has integrated wiki, bug tracking, and SVN repository with code browser. Pretty clever and looks nice. In python. But wiki is weak...

-- PeterMasiar - 29 Sep 2004

---

See also: LinkingTWikiFromCVS