MeatballWiki | RecentChanges | Random Page | Indices | Categories
1. The Goal
Also being considered:
- Switch to PostgreSQL? for support for 4-byte UTF-8 characters, as MySQL? denies these code points. (Need to consider whether full-text searches are as well-implemented in psql.)
- I never really considered MySQL? for serious stuff because of the long-time non–ACID compliance. If you want to use PgSQL?, you might look into the tsearch2 contrib module for full-text indexing/searching. -- anon
And everything listed as an InfiniteMonkey goal.
2. MVC choices
| || Model || Controller || View || Client-side |
Historical text from the original InfiniteMonkey. To be collated.
Here are the directions that it has to go in order to be a viable player on the web. Note that topics that require further discussion are listed in their own sections after this little list.
- Componentization. UseMod must be embeddable, in parts and as a whole, in other applications, especially weblog software like the ScoopEngine.
- Extensibility. Similarly, other components must be addable like IndexingSchemes and, to allow WikiLogs, weblog components.
- Code simplification. Altering the code should be tractable.
- Feature simplification. Special cases should be factored out of the mainstream and relegated to patches. Even so-called core functionality may be removed, such as RecentChanges. (Think how a separated RecentChanges could be changed to be a weblog a la BillSeitz 's blog, or to be UnifiedRecentChanges.)
- Patch simplification. Patching the code should be simple.
- Communal development. The script should no longer be controlled by one or two people, but by the larger UseMod community.
- Database improvement. The data structures should be simplified and made efficient.
- Presentation-oriented output. The current flow-oriented output is not as flexible or componentizable as we need; a template model would be better.
- Unity in diversity. There have been a number of competing upgrades to the UseMod core. I'd like to encourage such diversification without fragmenting the community.
- XHTML compliance. It's not sufficient to be HTML 4.0 transitional any longer.
- Improved use of cascading style sheets.
- Accessibility should be improved. That means such things as an accessible diff as well as maintaining standards compliance and Lynx friendliness.
- Globalization. cf. CategoryGlobalization. No more escape field separator non-sense.
- MeatBall:PublicScript, at least for MeatballWiki.
- Dismantling the useless and wasteful login system and replacing it with something more reasonable, if anything. Measure the disk usage of the login database against the page database; on MeatballWiki and UseModWiki they are about the same. Further, the login system really confuses people. Why the password? Who cares?
- Easy install. The install and configuration process should remain simple or become simpler.
- Meaningful and complete documentation, including a starter tarball.
Some new goals as of 2005:
- WikiSpam / Anti-troll defenses. The script should be hardened.
What are the odds of some sort of collaboration with other engines that have similar goals?
While originally I was thinking of a template-centric view originally, with InfiniteMonkey being a "workbench" for people to upgrade the base script, that is still too monolithic. I'm now thinking of a MicroKernel? view — of a sorts. MicroKernel?s don't work, but the cleaner the joins between one part of the system and the other, the more that can be built upon it (cf. StableBase). A strong OnlineCommunity should not just be a single hypertext, but it should be a NetworkService? (as inspired by TheProcessedBook). The architecture should somehow follow the people, rather than holding them hostage to some ridiculous interface. The UserInterface should be a client of the data server. If another engine already has a good interface, it may be better to connect the two rather than put everything into one monolithic project. Meatball should be ready for the upcoming DeathOfTheWeb lest it die with it, or lest it be forced to follow. -- SunirShah
Totally agree (except for upcoming death of the web? I guess I haven't been keeping up). See also [IntComm:ModularWiki]. The idea of breaking a WikiEngine into web service components is a special case of [OneBigSoup] (in [OneBigSoup] , the modules interoperate not only with other wiki components, but also with other online communications frameworks). And, a special case of [IntComm:ModularWiki] is [InterWikiSoftware:WikiWindow] (in [InterWikiSoftware:WikiWindow], the backend and the client are separated; in [IntComm:ModularWiki], each of those is in turn split into more, smaller pieces too). -- BayleShanks
Goddamn, I hate FreeLinks. I just wanted to make that clear. -- SunirShah, hacking
And then... nothing is nicer than seeing 109 tests succeed, 0 failed. Naturally, the next thing I do is break my code. The confidence of tests. -- SunirShah
I repeat. I hate FreeLinks. -- SunirShah
FileAttachment?s were remarkably easier, although still a pain. Somehow I am now up to 121 tests all of a sudden. -- SunirShah
By using the idea of "uploading a file onto a page" I was able to use all the SoftSecurity measures built into the wiki for file uploads as well — reverting, versions, authors, RecentChanges, etc. Attachments (ie. attaching files to existing pages) seemed to thwart SoftSecurity. How did you solve these issues? -- AlexSchroeder
I actually replicated the interface and metaphor from OddMuse, since it's ideal. (The code is different.) Attachments are really the wrong term, for this exact reason, so I've avoided writing the page. Socialtext uses 'attachments' just like e-mail. I'm not a fan. -- SunirShah
Working on the login & security system (yeah yeah, LoginsAreEvil). I actually store the user's preferences directly in their namepage as hidden fields. Let's see how far I can go without creating a new data structure. This thing is taking longer than I thought. It will take up to 3 days now. The nice thing about a clean dispatch system is that security is trivial. -- SunirShah
Today there are 112 categories in CategoryCategory. Perhaps all these categories are not related to each other
or perhaps there is some limit of categories for any wiki which suggests that a new wiki should be spawned.
I am going to suggest that a new wiki interface have a navigation sidebar containing categories. This I
think would speed navigation and lead to more focus around a particular wiki theme … (assuming the wiki
communitity actually wanted that). Of course, this would only work with bounded wiki categories.
Is UseMod 2.0 still in development, or has it been superseded by InfiniteTypewriter?
Basically, it's a version management problem:
So the answer is that UseModWiki 2.0 is not mine to answer and InfiniteTypewriter is indeterminate at this point. -- SunirShah
Could the current MeatBall version of UseModWiki be the next version?
Most of the features of UseModWiki — e.g. customizability, ease of installation, large community-built set of extensions, and lots of real-world testing on different machines — have been lost over time as the MB engine was developed. I'd say, a pretty big no here. -- ChrisPurcell
Another MVC choice could be the [Catalyst] framework. It's not so polished as the Ruby on Rails one - but it's in Perl so some code could be moved there directly from the current implementation and also it supports UTF8 in the language (as opposed to Ruby which is coding agnostic and does not support unicode in the language). -- ZbigniewLukasiak
Is it possible to see the code so far? I ask because I the description are written as to invite collaboration, yet I couldn't find an address of any repository or any snapshot. I'm sorry if I just didn't look close enough. -- RadomirDopieralski
Does InfiniteTypewriter have any code at all, or is it just a vision on this WikiPage at this time? -- SamRose
http://www.BibWiki.com runs on it, but I don't have time to package up the code. -- SunirShah