Archive

Archive for January, 2010

Release of Foswiki version 1.0.9

January 17th, 2010
1 comment

Release of Foswiki version 1.0.9, 17 Jan 2010

On behalf of the entire Foswiki community I can proudly announce the
release of the Foswiki patch release 1.0.9

Foswiki 1.0.9 is available for download from foswiki.org/Download/

Foswiki 1.0.9 was built 17 Jan 2010. It is a patch release with more
than 320 bug fixes relative to 1.0.0 and many small enhancements. This
release fixes many bugs in the Wysiwyg editor, bugs related to more
advanced wiki applications and bugs in the Plugin API. It contains
several bug fixes and enhancements related to security and spam fighting.

It is highly recommended to upgrade your Foswiki to 1.0.9.

The regular version (Foswiki-1.0.9…) is the full version with all
files. The upgrade version (Foswiki-upgrade-1.0.9…) contains the full
file package except the files that you will typical have tailored in
your installation and do not want overwritten when you upgrade. The
upgrade package will upgrade any version from 1.0.0 or later to 1.0.9
simply by copying all the files in the upgrade package on top of the
existing 1.0.X. The exact steps are described on the download page. If
you are at 1.0.0 there is no need to upgrade to 1.0.4 through 1.0.8 first.

Also note that many plugins and other extensions are being released or
updated every week. Follow the Extensions News at where important news
about extensions releases are announced.

foswiki.org/Extensions/ExtensionNews

The number of subversion code check-ins is over 6000 now and still more
developers join the project.

As release manager on the project I want to say a sincere thank you to
all the many that have worked hard on this release happen. A special
thank you to those that tested the two release candidates. Remember that
you can upgrade also the release candidates using the upgrade package.

You should also both when you download and install Foswiki and regularly
visit foswiki.org/Support/KnownIssuesOfFoswiki01×00 where we will
list the more annoying bugs that have been found and most often you will
find an immediate solution that you can apply.

We will be many developers that are ready to help you with the
installation of (or upgrade to) Foswiki on the IRC channel #foswiki on
the freenode.org network.

The special installer and virtual machine versions of Foswiki will be
updated to 1.0.9 version within the next days. Keep an eye on the
download page if you use one of these versions.

On behalf of the Foswiki Association and the entire Foswiki Community:
Enjoy the Foswiki 1.0.9

Kenneth Lavrsen
Release manager

Join the conversation also on our nabble-instance.

klavrsen development, extensions , , , ,

Are you shopping for a wiki: Look at Foswiki!

January 1st, 2010
5 comments

I just read a list of good arguments from Colas Nahaboo for Foswiki on the Foswiki mailing list and wanted to post them here quickly:

Our Foswiki at work (ILOG, then IBM) is in place since 2001, and has
now 60,000 pages. In my view, the main strengths of Foswiki wrt
mediawiki are:
* Utter reliability: it can run unattended for months without a worry,
it relies only on the filesystem. And if the filesystem is on a
NAS…. automatic continous backup for free!
* Resilience: it survives problems such as no more disk space, power
outages, hard disk failures with no damage nor curruptions
* Integration: you can use Foswiki pages as front-end applications to
services, or as display of programs results, as the engine just handle
text files that are easy to handle or generate by any scripting
language you like. For instance we use a separate search engine (now a
Google appliance) to provide full text searching.
* Power: If you are used to the unix way of thinking (data is defined
as simple text in files, and you use shell/perl/python/ruby/C/…
scripts to manage them) then any kind of feature can be added to
Foswiki as the engine is geared to having its data files changed by
other processes too, thanks to its dynamic nature. The great feature
of Foswiki is that users can code a feature via Foswiki Macros, and
other users can copy/paste this code which is not hidden like the php
of Mediawiki extensions.
On the performance problems, the main drawback of this dynamicity is
that a lot of things are recomputed on each requests, e.g. some
“macros” in Foswiki that search in pages can be slow. But things can
be optimised quite a bit by separating the contents into different
directories, and coding special scripts or plugins to optimize the
bottlenecks. Flat files are not slow per se (a grep in our 60,000
pages takes 10 seconds), it is just that we lack now the equivalent of
“indexes” you have with a database. But the community is working on
this.
I would add that wheter you choose Mediawiki or Foswiki, your
technical team is expected to learn to invest some time to unerstand
how the system works. I guess in the end the decisive factor is
whether your people are more at ease with php+mysql or with
traditional Unix scripting.
Colas.

Our Foswiki at work (ILOG, then IBM) is in place since 2001, and has now 60,000 pages. In my view, the main strengths of Foswiki wrt mediawiki are:

  • Utter reliability: it can run unattended for months without a worry, it relies only on the filesystem. And if the filesystem is on a NAS…. automatic continous backup for free!
  • Resilience: it survived problems such as no more disk space, power outages, hard disk failures with no damage nor corruptions
  • Integration: you can use Foswiki pages as front-end applications to services, or as display of programs results, as the engine just handle text files that are easy to handle or generate by any scripting language you like. For instance we use a separate search engine (now a Google appliance) to provide full text searching.
  • Power: If you are used to the unix way of thinking (data is defined as simple text in files, and you use shell/perl/python/ruby/C/… scripts to manage them) then any kind of feature can be added to Foswiki as the engine is geared to having its data files changed by other processes too, thanks to its dynamic nature. The great feature of Foswiki is that users can code a feature via Foswiki Macros, and other users can copy/paste/enhance this code which is not hidden like the php of Mediawiki extensions.
  • On the performance problems, the main drawback of this dynamicity is that a lot of things are recomputed on each requests, e.g. some ”macros” in Foswiki that search in pages can be slow. But things can be optimised quite a bit by separating the contents into different directories, and coding special scripts or plugins to optimize the bottlenecks. Flat files are not slow per se (a grep in our 60,000 pages takes 10 seconds), it is just that we lack now the equivalent of ”indexes” you have with a database. But the community is working on this.

I would add that whether you choose Mediawiki or Foswiki, your technical team is expected to invest some time to understand how the system works. I guess in the end the decisive factor is whether your people are more at ease with php+mysql or with traditional Unix scripting.

Colas

Read the whole mail-conversation including a happy ending here on our Nabble-documentation online.

mseibert tips , , , ,