“For a Wiki though the feed could soon get to big (several megs) if you had a large article with many revisions.”
I have an article that is 7 paragraphs long which I use to test the markup parser and the table of contents thing. So far it has ~20 revisions and hasn't crossed 100kb. I guess that is a really long article, but still, for even longer ones, there can be a significant increase in size with every revision. (especially if editors do dumb things like "typo fix" and all they change is an apostrophe)
I was actually thinking about a "purge" option, where the user would be presented with following:
1) ability to delete revisions before a specific date (on article base)
2) ability to delete all revisions besides the most recent one (for whole wiki, and for specific articles)
“BTW, why would an article need categories? Is there something different that you're doing about the hierarchy of the Wiki?”
I thought about having categories for grouping related articles (e.g. all articles about physics go under "physics" category) but I rethought it and decided not to include categories after all. Automatic rebuilding would require the application to re-read *all* articles on every load. Solving it with folders would limit the possibility of one article belonging into multiple categories without duplicating content. Therefore, I think it would be the best if categories are used for protecting pages from edits rather than categorizing articles.
“Discussion on Wikis simply suck. At least not to begin with, but something to consider is attaching a NNF-style comment thread to articles (or a talk page).”
I have actually considered to include this feature in the second version of the application. The plan for now is to get a plain and simple wiki engine with only bare functionality, and to build upon that for future releases.
“Just a small feature request, the ability to use the same trip codes from an NNF install.”
If you are referring to the authentication system -- that is the idea. :)
@martijn and jose
That isn't a bad idea, but I am not sure how it would work out. Seems to me that it'd require much work on the script end so that it could track changes and build the article through time. I think the purging system can do much more good here.