http://qs1969.pair.com?node_id=709202

Hi monks,

I'm planning Parrodocs, a Parrot project. I would appreciate reactions of any sort to the following outline.

As a first approximation, Parrodocs is a wiki system. It'll speak http://www.wikicreole.org and provide a revision control interface.

(I will merge my efforts into November-Wiki if that project's creators wish to incorporate what follows in a form I can use for a project that will build on Parrodocs.)

A central Parrodocs feature is that a page may be stored as a Perl6 string, and Parrodocs suitably sets up the context for interpolation.

So writers can incorporate variables like this...

This page, served by %ENV{$server-name}, is stored as a Perl6 string.

... and embed code by just typing braces (and the code of course ;):

This page is a Perl6 string which embeds code { ... }.

Per Perl6, pragmata enable use of any language spoken by the Parrot hosting Parrodocs:

This page embeds php code: { use pipp; ... }.

To implement WikiCreole, Parrodocs would define a variant of a Perl6 string that tried a WikiCreole grammar parse of those parts of a string that aren't code. So writers could write:

//This// page embeds php code: { use pipp; ... }.

to italicize "This".

Parrodocs will host itself. A first alpha version might be a single string / page / file / program that codes how to edit and save itself.

In contrast with the development norm, which is developers writing and storing blogs and wikis over here, and modules and scripts over there, coders developing or using Parrodocs will be encouraged to keep it together -- it may be that there are no dedicated program source files as such, just developers' journals, community discussions, design documents, and so on, all with code embedded in them. If, say, a class was defined in 10 places using "is also", a view would be available that suitably concatenates the 10 fragments into one virtual page.

I've got several other ideas I want to implement, such as using Junctions and other Perl6 language features within prose (I am a sany person after all). But enough for now. Thoughts?

Replies are listed 'Best First'.
Re: RFC: self hosting Perl 6 string wiki
by moritz (Cardinal) on Sep 05, 2008 at 09:12 UTC
    It sounds like a cool idea, but I have my doubts:
    • Security: contributing code in a wiki and executing it on the server sounds like a very bad idea in terms of security
    • Usefulness: why the heck do you need to run arbitrary code on a wiki page?
    • Maintainability: There's a reason why code and templates are usually separated, and that is maintenance.

    That said, I'm sure it's a very nice proof-of-concept demonstration of what parrot is able to run, or hopefully will be able. And adding wikicreole markup to November is certainly a very good idea.

[reply]

      Agreed, the security implications give me fits, but rolling new functionality into November sounds great.

      Applied things like November are the things that get me out of my "ignoring Perl 6" shell and actually looking into it.

[reply]
      Hey Moritz,

      Thanks for the feedback. Any more greatly appreciated.

      > Security:

      1. Parrodocs will run in a VM (eg openVZ). It will be possible to quickly restore a Parrodocs to a known "good" point. Data that must be any or all of persistent, secret, or ACIDly written, lives on a different server (eg an Amazon one).
      2. Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.
      (Due to the many misunderstandings I've read online over the years, I hesitate to mention Safe.pm -- "a failed experiment" -- and I wish to emphasize that use of such a module is not part of my plans at this point. That said, I still expect a useful Parrot version of Safe to be written within the next couple years and I would expect it to be useful in Parrodocs.)

      > Usefulness: why the heck do you need to run arbitrary code on a wiki page?

      Well, as another approximation, Parrodocs isn't really a wiki, it's sort of like a PHP (done right). (But please remember, this is again an approximation; please don't respond with "I hate PHP", because Parrodocs is really a squeakish Perl6/website IDE. Well, actually it's a platform for experimenting with non-linear communication. Well ... urgh. Part of the point of this meditation was to work out which part of the elephant to describe first next time I try.)

      > Maintainability: There's a reason why code and templates are usually separated, and that is maintenance.

      Newbies don't care about maintenance, and they'll be delighted that they can just write "Hello $mom" and it'll DWIM. In contrast, an advanced developer might want total separation -- perhaps an XML + XSLT solution. I think Parrodocs will cover both extremes and variants in between.

      I look forward to any further thoughts from my fellow Monks...

[reply]
        Parrodocs will run in a VM (eg openVZ). It will be possible to quickly restore a Parrodocs to a known "good" point. Data that must be any or all of persistent, secret, or ACIDly written, lives on a different server (eg an Amazon one).
        That doesn't account for attacks that can be used to steal passwords from other users (think of CSRF, faked login screens etc.), which kinda defeats your next point:
        Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.
        If you can steal account data by manipulating everything that's visible on the page, accounts loose their value.
        Well, as another approximation, Parrodocs isn't really a wiki, it's sort of like a PHP (done right)

        I'm happier with that description. But if it's more like PHP than a wiki, where is the connection to (update: ... november)

[reply]
Re: RFC: self hosting Perl 6 string wiki
by ambrus (Abbot) on Sep 05, 2008 at 10:30 UTC

    How's this any better than Wikiplia, apart from that the Wikiplia server has been down for a while now?

[reply]

Back to Meditations