Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

writing add-ons in languages other than php

edited February 2008 in Vanilla 1.0 Help
Just curious. Can it be done? has it been?

Comments

  • Options
    The server would need to be able to parse the other language and it would need to do so when the script was called from the include() call...but yeah I guess so. Why?
  • Options
    I dunno. Potential armys of add-on developers who use python, ruby, newlisp, rebol, or whatever, but not php.
  • Options
    In theory, yes. In practice, no. You'd have no access to Vanilla's API.
  • Options
    hm, this sounds good. I'll think about it.

    There must be some way how to pass the API to another language. It would be slower but it is possible I guess.
  • Options
    I really don't think it's possible unless you somehow write an interpreter for the other language in PHP. I suppose you could do that but it'd be easier to just rewrite Vanilla in the other language. Racking my brain here for a second; it might also be possible to provide an intermediary PHP script which processed special commands in the form of POST or GET data and returned the relevant information in a language-independant form (perhaps JSON?) so that the other language could read it. Building a scaleable, flexible infrastructure for that sounds like an interesting project but it would require a lot of work. Also, it would be really, really slow. There's also the barrier of getting the webserver to somehow work with two languages. If you were to write a CGI script in C++ or something then it might just be possible. In all, yes, I've changed my mind; it is possible. It's just very complicated. If anyone's up to the challenge they are quite welcome to it.
  • Options
    I think it wouldn't be so complicated, just not so secure and fast. My first completely not tested thoughts:

    One can make a addon which would contain subfolder scripts/ and do something like this:
    $descriptorspec = array( 0 => array("pipe", "r"), // stdin 1 => array("pipe", "w"), // stdout 2 => array("pipe", "w") // stderr ); $scripts_dir = $Configuration['EXTENSIONS_PATH'].$EXTENSION_NAME.'/scripts/'; foreach ( executables( $scripts_dir ) => $script) { $process = process_open ($scripts_dir.$script, $descriptorspec, $pipes); fwrite($pipes[0], serialize_context()); fclose($pipes[0]); $stuff_to_unserialize = stream_get_contents($pipes[1]); fclose($pipes[1]); if (proc_close($process)) { unserialize_context_and_delegates($stuff_to_unserialize) } }
    where:
    executables returns list of executable files in a given folder
    serialize_context would parse Context to some serialized format with info if this is first call or delegate call
    unserialize_context_and_delegates would read some serialized data where would be:
    - what changed in Context
    - what delegate calls what function
    also it would create delegate functions and hook them.
    Each created delegate would look like this:
    function DelegateFor{$script}{$FunctionName} () { // some initialization here $process = process_open ($scripts_dir.$script, $descriptorspec, $pipes); fwrite($pipes[0], serialize_context_and_delegates('$FunctionName')); fclose($pipes[0]); $stuff_to_unserialize = stream_get_contents($pipes[1]); fclose($pipes[1]); if (proc_close($process)) { unserialize_context_and_delegates($stuff_to_unserialize) } }
    where
    serialize_context_and_delegates would prepare the Context as serialize_context() but also would add info, that this is a delegate call and which one

    So it would call the external script when it is initialized and also when each delegate is called.

    Then you can have script even in a bash script.

    Also I got an idea that there in scripts might be only some interface scripts for each language you want to use and it would read the real scripts from other places.
    It would be also possible to return another script name for a delegate calls, so you can split your add-on into more scripts and call only those you really need in the delegation.

    These interface scripts would read the serialized input from stdin - status, if this is an initial call or delegate call, prepare $Context to the language specific type.
    If it is a delegate call, it would call the delegate only, if initial call, then init function only.
    It would also define ChangeContext function which would change anything in a context and it would also prepare the data to return concerning the changes in the context.
    And it would also define Delegate function which would be called if you want to delegate any function in the script and prepare the serialized delegation info.
    At the end it would pass the context and delegation serialized data and return an exit code.
  • Options
    There would be also needed some other things, like getting html output from delegates. It was just first thought :)

    And I haven't think about another IPC communications yet, but stdin/stdout is available on all platforms.
  • Options
    You'd need to make sure your server allowed PHP scripts to perform those sorts of functions as well as ensuring that it had things like python or ruby. Also, stream_get_contents is a PHP 5 only function and Vanilla is written in PHP 4 to be as widely-accessible as possible. Other than that, your version does seem less complicated but it is also slower and less secure than a CGI C++ wrapper for the whole of Vanilla. Even so, I'm quite interested, I might make a proof-of-concept version for people to play around with if they're interested.
This discussion has been closed.