faq-o-matic versus twiki
Read this article only if you care about collaboration software.
I once considered Faq-O-Matic (called fom in the rest of this document) as a replacement for my favourite web software, TWiki. So I installed fom on my home machine, and went through the entire documentation and assorted material to see what features fom has and how they compare to twiki.
Yesterday we had a discussion on these topics, so I pulled it out, reformatted it very slightly, and put it up on my website.
summary: twiki is more laissez'faire, fom is more rigid
structure of content
fom imposes a hierarchical structure on content. re-orging the entire tree is easy enough, and makes for "book like" content to be made
twiki, on the other hand, is more anarchic in terms of relationships. paradigm is closer to the web itself, where there really is no beginning or end or implied sequence except in very localised contexts
show entire category
since fom has a tree structure, you can expand the whole thing and get the whole shebang right there. great!!
this is why fom allows you to deny HTML usage completely, because otherwise one maintainer's bad HTML can screw up the entire display!
proof of this screwing-up is in the fom admin guide itself!
but I dont really like denying HTML completely...
delegation and granular control
in fom, different people can be made responsible for different subtrees of the fom tree, in terms of content, admin, and (re-)organising. this is good for more organised and hierarchical groups
in twiki, anyone can do anything anywhere; it is not easy to create such granular access as in fom (except in webs). this is better for groups where everyone is notionally equal
like above, fom seems to be better at controlling attachments
but twiki's handling of attachments seems more intuitive. also, I have to check if fom's "bags" are version controlled; the ability to version control even attachments (and see older versions if needed) is a wonderful part of twiki.
speed versus update frequency
twiki is slower, due to the way things are rendered from scratch every time. however, every page view you see is guaranteed to be the latest. twiki's are actually very dynamic so this feature is not likely to change
fom, otoh, is faster due to the caching that is done everytime you write. a minor penalty is that things that affect the view, but are not part of the page (like system-wide configuration) does not reflect in pages that got cached, until someone flushes the cache or something. [may not be a big deal... need to test]
fom has virtually none, unless you use HTML...
...although I wish that at least bullet lists etc would have a way out, since this makes it pretty useless for my style of writing (the PPT style!!!)
twiki has great stuff plus you can always use HTML
[if we were to seriously consider fom we must put in at least my t2h.pl functionality...]
dynamic linking by topic name
a huge, huge, plus for twiki!
fom has very basic search... not at all fundoo. but it is fast -- uses a database
twiki is slower but has great search controls. the full search page for twiki is quite complex and very cool!
fom has a text-based but complex format, needing exotic "fsck" type integ checks! each "topic" does not stand on its own, but is linked with others; there can be no orphans!
twiki has plain text files for topics, with only a little meta-data cruft at the top and/or bottom. in particular, each topic is a separate entity, with no external (file-system level) dependancy on any other topic, for consistency. the wikiword concept is an absolute god-send
this also makes migrating fom to another server a complex task. on twiki you just move the files for the topics you want and place them where you want!
upgrading also becomes messy -- see how complex the upgrade instructions are in the fom admin guide (different steps depending on different source and target versions!)
however, the "parts" business seems to have some potential...???
the whole cache business is messy; absolute URLs all over the place...
fom needs a maint cron job; I dont think twiki does. this causes problems (in fom) for HTTPS environments, it seems...
[only time twiki needs cron is if you want to enable the "change notifier" emails]
size of articles due to format/RCS
needs to be checked
authentication and access control
fom seems to do a better job; the simple way in which it mails you a password is quite nice. of course I've already rolled that as an external addon for twiki (not really integrated but at the top page of the website)
however, in spite of this, the ease with which subparts can be separately access controlled is wonderful. twiki not being hierarchical at all, this would be impossible anyway
even more awesomely (on fom), the way that it allows you to say "anyone with an email ID in this domain can post" is great!
of course, it should be remembered that twiki does not actually do any access control at all, preferring to leave it to apache!
curiously, people (on fom admin guide) seem to prefer the "let the web server handle it" approach :-)
and as someone said, you cant make it disallow reading without the help of apache, so all this is moot. no point having write security in fom, and read security in apache -- best to leave it all to apache like twiki does, and add wrapper scripts like I have... (hell its a simple script anyway)
for end users in fom is tough and very scanty. compared to the oodles of stuff twiki has, fom is quite pathetic!
even for admin its no great shakes...
doesnt work in classic (Apache::Registry) mode. need to check if twiki does, but it should...
is there but you cant see old data from the web, like you can in twiki!
this is a major minus for me, I would like all users to be able to see old versions, not just the admin guy!
check in twiki for sub-webs... does devel version have it?
[I think someone added it; whether it went into the mainline twiki distro I have to check] would be very useful
some missing features in fom
pages changed since...
diffs (this is related to seeing older versions)