Proposal and ProofOfConcept implementation.

What if Wiki pages could have PerlLanguage scripts buried in them that actually ran on the server? 

They would execute in a safe sandbox, of course. API methods give access to make modifications to the page, read other pages, and use other pages as modules.

The code escape syntax is the same as ASP, ActiveWikiPages's namesake. The instruction to read another page into a namespace of the same name is ''sb_use('Page''''''Name');''. Modules have read/write access to the pages that use them.

Automation of things like message boards, hit counters, image uploaders, and so forth could be created. 
When used as a module, providing pages a means to automatically link back to any page that links to them.

Perl scripts could InTheory generate graphics on the fly and add them to the page - TinyWiki handles graphics as UUENCODE'd blocks of data in the page which a support script decodes on the fly. I'm working on a minimal implementation of an image generator that creates non-compressed GIF images. One of my goals is to create diagrams on the fly - this has proven to be a requirement for the PerlPatternsRepository.

Given a limited HTTP fetch API for doing GET operations on specified domains, InterWiki-like integration could be implemented in a laissez-faire fashion. Example code could be run without having to download it. The trust metric system could be reworked to provide a public API. The possibilities are endless.

While such extentions may seem at odds with the concept of Tinyness, creating a sandbox is trivial in Perl, costing one line of code; undef'ing dangerous functions costs another line; the grammar rule costs a line, creating new functions to read arbitrary pages, append to the current page, and using pages as modules each cost a line, for a total of 6 lines. This facility is reused to implement active headers and footers, and enables the core to stay tiny while cool features are added in user-land.

This is indeed ReflectiveWiki-like, but only in proportion to how much of the functionality is implemented in user-land. In theory, the Wiki grammar, "save" logic, and so forth could all be moved into scripting in pages. The core would then bootstrap setup a sandbox including an API for Wiki to use, and then bootstrap itself from a page. A separate script to roll back the bootstrap page would be needed to un-paint yourself from a corner should things go wrong.

As far as ReflectiveWiki being "absurd", as its original proposer said his initial feeling was, one of my goals is to support various types of output: TinyWiki was created to allow collaborative development of a book. HTML output is useful for working on it, but ultimately it would need DocBook or LaTeX output. Alternate parsers could be specified by pages, so that pages could be marked up in PerlDoc or JavaDoc instead.Far from absurd, I think ReflectiveWiki is brilliant.

This project is part of TinyWiki for the PerlPatternsRepository. Yes, the code is available. - ScottWalters

----
See TinyWiki, ReflectiveWiki, InterWiki