InfiniteTypewriter

MeatballWiki | RecentChanges | Random Page | Indices | Categories

InfiniteMonkey — Overarching project.
InfiniteTypewriterDatabase — Database model.

1. The Goal

Separation of Model, View and Controller (e.g. with Rails).
A MachineInterface, using a sane set of canonical URLs.
A decent data structure.
Emit web standards (XHTML and CSS), ultimately moving to wysiwyg.
Javascript ITMarkupEngine using novel regular expression–recursive descent design
Wiki:ProgrammerTests.
RapidAntiSpam, and in general, using a Rest:HttpEvents MachineInterface to keep machines synchronized.
AsynchronousAutorefresh on the browser end.
SingleDispatch logging & security
EthnographicResearch?
StringTable?s for internationalization
The basic PageModel
MeatballWiki as NetworkRepository
MeatballGlobalization
A better OpenProxy detector
PermanentAnchors
ParentPages as an RDF extension over the main core
Relocate indices from sunir.org to meatballwiki.org

Also being considered:

AggressiveCaching
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

LinkTypeIcons

And everything listed as an InfiniteMonkey goal.

2. MVC choices

	Model	Controller	View	Client-side
Original plan	Rails on MySQL?	Rails	Ruby templates	Javascript
Current plan	Rails on MySQL?	Rails	XSLT with Javascript extensions	Javascript
Possible final goal	Javascript on SQL	Javascript	XSLT with Javascript extensions	Javascript and XSLT

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.

-- SunirShah

Some new goals as of 2005:

MachineInterface. The entire wiki should have MachineInterfaces in RFC 822 style. The internal data store should be as RFC 822–like as possible.

WikiMarkupStandard / WikiInterchangeFormat. The syntax translator is built around a rhetoric-based parser model, and thus form the kernel of a universal translator between all WikiSyntaxes. What is a rhetoric-based parser model?

WikiSpam / Anti-troll defenses. The script should be hardened.

ElectronicPaper. Build towards digital paper obviating UniformResourceLocator-based SemanticSpace.

FairSoftware. Build InfiniteMonkey into a WikiAsSourceControlRepository to support FairSoftware.

OpenAcademics. Support for OpenAcademics built directly into the script.

-- SunirShah

3. Discussion

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. -- BobMcIsaac

Is UseMod 2.0 still in development, or has it been superseded by InfiniteTypewriter?

Basically, it's a version management problem:

Cliff has dropped off the 'Net.
InfiniteTypewriter hasn't really started.
MeatballWiki is in an undefined state right now
InfiniteMonkey, the wiki engine, plus a truckload of un-unit-tested hacks are underlying the DesignBibliography.

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

CategoryMonkey