v8cgi 0.9.1 released!

[ondras]

Hi all v8cgi fans,

a new version, 0.9.1, was relased. This is mostly a bugfix release, containing all the patches and changes done in the last months. This release does not bring any new features to those who use SVN trunk revisions, but may be useful to those who use packaged releases.

v8cgi is now threadsafe (can be run with apache worker mpm) and was improved in several areas (global object reusing, HTTP uploads, SMTP).


Have fun,
Ondrej Zara

[Michiel Crefcoeur]

I really like the way JSDB handles streams, check it out!

JSDB has been around for quite some time now and is really stable.

It's based on SpiderMonkey.

2011/9/27 Wes Garland <w...@page.ca>

On 27 September 2011 07:43, Oleg Podsechin <oleg.po...@gmail.com> wrote:

I do feel that there is a need for increased collaboration among synchronous server side JavaScript implementations.

I agree, 100%.   Ondras and I speak frequently about implementations, and I have certainly found his experience useful when building similar modules in GPSEE.

- a single, cross implementation utility package containing the fastest pure JS utility modules (I'm trying to put something together at https://github.com/olegp/common-utils)

I think Dean Landolt started something like this last year; also, you should definitely look at Narwhal. Lots of good reusable stuff in there.

Finally, you absolutely *must* look at Christoph Dorn's PINF loader.
 

- have all implementations support the same base CommonJS specs and have a separate package containing a bunch of unit tests, so that we would have one set of tests & to speed up development of new implementations

I agree 100%.  However, we still need to get some very important spec pieces ratified.  Like I/O streams. There is a ratified CommonJS spec which will let you open files, but not read them. That's so stupid. In fact, every time I think about how this group spent a full year arguing over module formats -- without a portable way to even read files -- my blood boils.

There is a good start in the Wiki that is implemented by RingoJS.  I think Streams class in GPSEE is about as minimal as you can get and still be useful; I grafted that onto the end of the fs-base module, awaiting a real spec.

Also, I think eventually we should aim to have fewer implementations per engine.

What value does absence of code bring to the ecosystem?
 

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.

To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Oleg Podsechin]

Sorry, I should have rephrased that last point. What I meant was that there should be *even more* collaboration amongst the implementations that use the same JavaScript engine so as to avoid writing redundant code.

[Michiel Crefcoeur]

I haven't really used it that much either but from all the stream implementations I've seen so far, JSDB's Stream class and the various ways in which it can be used looks the most mature to me.

Stream reference:

http://www.jsdb.org/jsdbhelp.html#Stream

It can be used to open files, do HTTP requests, open sockets, spawn processes and create in-memory FIFO buffers.

cheers,

Michiel

2011/9/27 Wes Garland <w...@page.ca>

> What I meant was that there should be *even more* collaboration amongst the implementations that use the same
> JavaScript engine so as to avoid writing redundant code.

Ah: that makes a lot more sense.  This is one of the key design elements behind GPSEE: to allow us to share native (C, C++) modules/code between platforms.

Michiel, can you give us the ten-cent tour of JSDB's Stream API?  I am aware of the product, but have not used it. I had considered re-using part of his product at one point in time (since we are both SpiderMonkey) but the license terms didn't work for me.