Re: New PECL package request: ecmascript
| From: | Alexey Zakhlestin | 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/