phpwiki-talk

[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

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

[Reini U. <ru...@x-...>]

Mario Salzer schrieb:
>   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/

Thanks,
I have looked at this before, but I will do again, since it is quite 
interesting.

The reason why I looked at this before is to disallow unsafe user-side code.
I added a similar project to phpwiki core then. a "sandbox" htmlparser, 
which skips unsafe html parts, for our RawHtml plugin.

I doubt that "safe" javascript will be of much use to us, because our 
philosophy is to disallow complicated rendering markup, make it simple 
and uniform. Besides the obvious to disable any abusable user-side code.
normally admins can easily extend their templates with javascript.
But we will see, if it makes sense for users also.

>   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.

hmm, a cross-wiki scriptable language? I'm not really convinced.
similar to the unification of wikisyntax.

why not using php for all php-based wiki's (similar for the perl-based 
wikis), and just unify the API for the plugins?

>   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.

But technically I would have no problem to support your "WikiScript" 
plugin idea, and users can play with it then. If it will be fast enough...

Do you want a detailed description of our plugin API?
Or should I just code it for you as an example?

mediawiki is similar, others not that much.
I believe that our plugin syntax is the most advanced, but we should 
make a wikipage to list the differences and decide then.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

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

Reini wrote:
> The reason why I looked at this before is to disallow unsafe user-side code.
> I added a similar project to phpwiki core then. a "sandbox" htmlparser, 
> which skips unsafe html parts, for our RawHtml plugin.
>
> I doubt that "safe" javascript will be of much use to us, because our 
> philosophy is to disallow complicated rendering markup, make it simple 
> and uniform. Besides the obvious to disable any abusable user-side code.
> normally admins can easily extend their templates with javascript.
> But we will see, if it makes sense for users also.

The phpjs thing has improved since you last looked at it: It now
comes with an accelerator which could convert the bytecode back
into (extensively sandboxed) PHP code, so it should run almost as
fast as native scripts. Though you loose control by that, since the
old interpreter could in fact be modified to prevent endless loops
or other time consuming script bugs.

Also I personally don't believe that this whole idea will get over
the toy status anytime soon, and it definitely isn't worth using
it for core features. But advanced search interfaces and customized
RecentChanges-plugins are a real opportunity, and users would
certainly play with it then.


> hmm, a cross-wiki scriptable language? I'm not really convinced.
> similar to the unification of wikisyntax.
>
> why not using php for all php-based wiki's (similar for the perl-based 
> wikis), and just unify the API for the plugins?

Yep, standards adoption is always a problem, especially with the
WikiMarkupStandard - but actually having a different syntax also
protects a bit from spammers these days.

The unified native API for PHP-based Wikis may eventually come as a
side effect here. That WikiScript idea only needs negotiated JS-
function names, but nothing stops us from also negotiating on a
common naming scheme for the actual interface functions.
For the version I've started I choosed to prefix all PHP function
names with "wikiapi_" - so that what will later get "wiki.getPage()"
in the phpjs interpreter corresponds to the native PHP function
"wikiapi_getpage()".

Currently the native internal interfaces of the existing
PHP-engines are too different to get unified:

- PhpWiki: $db->fullSearch($searchobj)

- ewiki: ewiki_db::SEARCH($field, $str, $ci, $regex, $filter);

- Media: SearchEngine::doFuzzyTitleSearch($search, $fname)

That's why I think we'd first needed some glue functions here. We
shouldn't treat this a major goal, but if it happens that we could
do this, then let's try.

But btw, using JS-plugins has the benefit that (already planned)
once a similar interpreter existed for Perl, all Perl-based Wikis
would benefit from the existing cross-Wiki plugins; same for Python.
Maybe I shouldn't speak this out too loud, since I haven't even
finished the PHP-version, but anyhow - the idea is funny :)


>
> But technically I would have no problem to support your "WikiScript" 
> plugin idea, and users can play with it then. If it will be fast enough...
>
> Do you want a detailed description of our plugin API?
> Or should I just code it for you as an example?
>
> mediawiki is similar, others not that much.
> I believe that our plugin syntax is the most advanced, but we should 
> make a wikipage to list the differences and decide then.

Uh, oh, uh - I can prove that you're wrong on this one!
PhpWiki does not have the most advanced plugin syntax, and I must
know - because we adapted our engine to use the same!  ;-)

At least it looks the same and works (our plugin API is far less
sophisticated than yours). Whatever, I guess I could write the PhpWiki
plugin myself then, shouldn't be all too complicated. Where I need
help would be the WikiScript interfaces.
Since those make sense, the XmlRpc are likely candiates to become part
of that "WikiScript API" - so half the work is already done.

It's only important that the API won't get too powerful, since the
only thing I definitely don't want to see anytime soon was a
"WikiScriptVirus" or even worse: "InterWikiScriptViruses" ;-)
(even if it would be nice to see so much union between WikiEngines
to get anywhere near such problems).
What I wanted to say: the API should consist of read-only interfaces
mainly, and the rest must be taken with care - else even the safest
sandbox scripting language won't bring useful cross-wiki plugins.

mario


-- 
http://erfurtwiki.sourceforge.net/
http://opensearch.berlios.de/