[Phpwiki-talk] "WikiScript" for cross-WikiEngine plugins

[Mario S. <ma...@er...>]

  Hope this is interesting to anyone... I'm from a concurrent
  Wiki project (http://ewiki.berlios.de/) and currently into
  hacking a JavaScript "interpreter" in PHP:

    http://phpjs.berlios.de/

  Most people now will ask, what JavaScript could have to do
  with PHP - but this thing is running server-side, it is an
  interpreter itself run inside of the PHP interpreter. This
  is only useful, because this way you get a safe runtime for
  user-supplied scripts.
  For a Wiki this means that users could inject small scripts
  into pages and extend the site that way (see also MetaBall:
  CommunityProgrammableWiki) - you would be mad if you allowed
  users to feed bare PHP code on your server through eval().

  Before you look at it: that phpjs interpreter isn't finished
  yet, misses OO-features and a few language constructs - just
  a toy currently (though it could be configured to emulate
  PHP quite well).

  The idea I had some time ago, was to allow ALL users to write
  (limited) "plugins" that would run in different WikiEngines,
  without having to code for its native/internal functions. This
  is partially discussed on:
  http://wikifeatures.wiki.taoriver.net/moin.cgi/AutomaticFeatureInstall

  Now to really get cross-wiki compatible plugins, you not only
  need to have the scripting language which should look the same
  for all implementations, but you also have the API - which of
  course needs to provide similar features here and there. As today
  everybody knows, JavaScript in browsers failed somewhat at this,
  because of the many non-compatible extensions MS and Netscape
  introduced.

  So before I'm going to start an example implementation of
  what I think could be called "WikiScript" or so ;)  I'd like
  to ask you PhpWiki folks what you think about, and if you're
  interested at all. The other PHP-based Wikis currently look
  too small or unprofessional, so I'm asking here first.

  What really matters most is the API, it needs negotiation to
  later get scripts working in different WikiEngines. I also
  had no problems of just starting my own version and simply
  design an API tailored to what I need, but the compatibility
  idea is even more interesting than the user driven injection
  of new features.

mario