Migrating Foswiki 1.1.9 on Ubuntu to Foswiki 2.1.6 on Docker
Foswiki, Alpine Linux and Docker
How to improve your WebIndex in Foswiki
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:Read the whole mail-conversation including a happy ending here on our Nabble-documentation online.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
- 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.
