Re: New PECL package request: ecmascript

From: Date: Wed, 10 Sep 2008 19:47:34 +0000
Subject: Re: New PECL package request: ecmascript
References: 1 2 3  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-5743@lists.php.net to get a copy of this message
On Wed, Sep 10, 2008 at 9:10 PM, Fran Rogers <frogers@nutmeg.ws> wrote: > On Wed, 2008-09-10 at 10:13 +0400, Alexey Zakhlestin wrote: >> On Wed, Sep 10, 2008 at 6:02 AM, Fran Rogers <frogers@nutmeg.ws> wrote: >> > Hello PECL developers, >> > >> > I have been developing an extension to embed ECMAScript (the >> > industry-standardized language of which JavaScript is a dialect) into >> > PHP, using the SpiderMonkey engine from Mozilla, and I am interested in >> > applying for an account on PECL with CVS to host and distribute it. >> > >> > I will release the extension under the PHP License 3.0. The Mozilla >> > Public License of SpiderMonkey is compatible with this (see MPL clause >> > 3.7, "Larger Works"). >> > >> > The way the extension works is similar to that of the (unfinished?) Lua >> > extension in PECL's CVS: the ECMAScript environment is encapsulated in >> > an object, and the variables and functions in that environment may be >> > manipulated or called from PHP as properties of that object, with >> > automatic conversion between ECMAScript types and Zend Engine types. >> > Strings of source code can be called from the context of a given >> > environment. PHP code can also be exposed to the script's environment by >> > creating functions in the environment with an attached PHP callback. >> > >> > I think this extension has quite a bit of potential - I initially >> > started developing it for an extension to MediaWiki to allow site >> > administrators and users to add custom functionality and hooks to their >> > wiki's parser on-the-fly using JavaScript, without needing to >> > reconfigure the software at the PHP level. As the script's code runs in >> > a sandbox environment, as much or as little of the "outside world" as >> > needed can be exposed. INI settings also allow the script's execution to >> > be limited, to prevent accidental or maliciously deliberate endless >> > loops and excessive memory usage. >> >> That will be a great addition to PECL. I would be glad to test it >> extensively, once it is in :) >> >> > I am interested in registering this new PECL package under the name >> > "ecmascript". Is this OK? >> >> "Ecmascript" is too general, IMHO. >> There are several open-source implementations of ecmascript except >> spidermonkey, and there is always a chance, that someone else would >> come with idea of creating binding to V8 or SquirrelFish >> > > That is a good point - ideally, though, this "ecmascript" extension will > support other ECMAscript implementations in addition to SpiderMonkey, > selectable via compile-time configuration options. (As of now, the > SpiderMonkey-specific code is limited to a single file, so adding > support for other engines should be pretty straightforward.) The > interface it exposes to PHP is rather high-level, and it would be great > to allow programmers to write PHP code for the "ecmascript" extension, > while server administrators would be able to compile the extension using > whatever engine is most convenient for them. well, sounds good I doubt anyone will be against Do you have PECL account? If not, you should proceed with form: http://pecl.php.net/account-request.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

« previous php.pecl.dev (#5743) next »