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/