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('PageName');. 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