AutomaticFeatureInstall

We can design our WikiEngines in interoperable ways.

Once that is done, it is not terribly difficult to fetch the code for a new feature from a trusted source, install it, and let users use it, all automatically.

These days, the operation of most wiki depends heavily on the maintainer of the wiki. If you want to make any changes to the wiki, you generally have to bother the maintainer to install the feature.

Once the maintainer has decided to install the feature, it is a long and sometimes complicated task. It may require setting disk space aside, requesting scheduled time from the system (by “cron,” for example), custom hacking of the software code, addition of new user configuration options, or any other tinkering with the system.

Thus, the adoption of new features is generally slow, and strongly tied to the release cycle of the WikiEngine itself.

However, it doesn’t need to be like this.

We can design our WikiEngines in interoperable ways.

Once that is done, it is not terribly difficult to fetch the code for a new feature from a trusted source, install it, and let users use it, all automatically.

Possibilities

Internal Interfaces

The developers of WikiEngines could collaborate on standard interfaces to WikiEngine resources.

That way, feature developers could write features that work on many WikiEngines, not just one.

Feature developers need access to things like the page database, user data, user configuration options, periodic CPU time, and disk space for caching.

Parrot

Wiki developers tend to favor scripting languages such as Perl, Python, or PHP.

Right now, if you make a WikiEngine in one of those languages, you are pretty much “stuck” with that language. You can’t take something written in another language, and mix it in.

That means if we get AutomaticFeatureInstall, you could only install features that were implemented in the language your WikiEngine was impelmented in.

But there is a new thing, called "Parrot," that will likely make it so that Perl, Python, PHP, Ruby, and Tcl programs can work with each other.

If Parrot works, and wiki developers get their code to run on Parrot, then people can share features without regards to language. That is, provided that they share Internal Interfaces, as described above.

But you know that this was an April fools joke, and despite that website there is even no O’Reilly book on it? – MarioSalzer

It was an April fools joke, but it’s real, now. Larry Wall has firmly committed to it.

And, there is an O’Reilly book on it- (beyond the joke book-) it’s called Perl 6 Essentials: “This book covers the development not only of Perl 6 syntax but also Parrot, the language-independent interpreter developed as part of the Perl 6 design strategy.”

In a message dated January 6th, it appears there is an effort to put Parrot into Mozilla as well. Who knows? Perhaps JavaScript will be running on Parrot as well..!

StupidScript

MarioSalzer: (Ho, that’s how I generally call it). But to get real, I believe it would help if there existed a JavaScriptInterpreter implementation for use with Perl, PHP (but not Python, *argh*!!!). This would ease development and would make the FeaturePlugins interchangeable across Wikis in whatever language, provided that there really was a standardized and basic interface - think of objects like wiki.getPageById(); or so.

Right now there are only P-language external JS interpreters (NGS JS), but I guess it was possible to chain the Mozilla JS engine to PHP or Perl someday. This eventually would also allow to use that fancy .xpi thing to really make the feature installation automatic (“upload plugin here”).

WikiMarkupStandard

Also think about a “text/wiki” MIME Type and have support directly in Mozilla. Then we could use its rendering and its JS engine to do all this. (But this then would obsolete most parts of current WikiEngines.)

Generalizing

You can generalize this concept out from just features.

For example, you could make it so that “smileys” could be requested, and installed, from other WikiEngines. Smileys require no code, and aren’t exactly what we think of as a “feature.” But it’s a good idea, and easy to work.

Implementations

Presently, no WikiEngine supports this feature.

However, MoinMoin is rather interesting in that it has a sophisticated plug-in architecture. You only have to know a little bit about the engine to create macros, interpreters, parsers, actions, or formatters. It’s not quite as good as having standard internal interfaces, but it is very close.

Activity

MoinMoin continues to work on it’s plug-in architecture.

BayleShanks has been vocal about this idea.

PWiki2 uses functions to plugin new features easily and seamlessly. You simply write a new function eg: foo.php, place it in the functions directory and you have yourself a new feature. This is how DatabaseCapabilities was developed in PWiki2. --JamesMills

Yeaaaah, but that’s not quite it. MoinMoin has a zillion plug-in capabilities. But it still doesn’t have AutomaticFeatureInstall.

We’re talking like point-and-click feature install. You say, “I want that,” and all the necessary code is loaded into your system, and just works.

The wiki needs another page to talk about general plug-in capabilities. – LionKimbro

Terminology

Internal Interface - An convenient interface to the resources of the WikiEngine. Intended for use by automatically incorporated features.

Problems

WikiMarkupStandard disagreement

There is a lot of disagreement over a CommunityWiki:WikiMarkupStandard.

Possible solution: An intermediary format? Just more standards work?

Possible solution:Instead of having the wiki server convert the raw plaintext in the wiki database to HTML, it just sends that to the user’s web browser, with a reference (<SCRIPT LANGUAGE="JavaScript" SRC="filename"></SCRIPT>) to a Javascript (or Java?) program that reformats it on the user’s end. You could have several different javascript files… Let every page indicate which markup standard it uses (perhaps with some sort of “#pragma” statement).

Some kinds of features can be implemented by adding a new JavaScript program to run on the user’s computer (for example, FilteredRecentChanges).

Contributors

LionKimbro, MarioSalzer, DavidCary

(Thanks to BayleShanks for telling me the idea.)

CategoryFeature CategoryInterWiki