
Mod_v8 - davidw
http://journal.paul.querna.org/articles/2008/12/23/mod_v8/
======
geuis
Its this kind of thing that makes me think karma is a real thing. I've spent
the last 2 days working on getting Rhino to work with lighttpd. Haven't gotten
far, mainly problems getting lighttpd running on Mac OS X. Either way, its
really nice to see other people working on variations of the same theme.

~~~
nikils
<http://jsext.sourceforge.net/> supports lighttpd

------
smoody
What any server-side javascript implementation needs to thrive is a set of
solid, fast database client libraries (MySQL, etc). That, to me, is why some
of the JVM-based alternate language implementations are so interesting --
because the database support is built-in.

~~~
tlrobinson
Unfortunately Rhino is at least an order of magnitude slower than all the
modern JavaScript engines (SquirrelFish Extreme, V8, TraceMonkey). I agree the
JVM integration is very useful, I just wish there were a way to get the best
of both worlds.

~~~
jerf
Port <https://wiki.mozilla.org/JSctypes> to v8, get C libraries for, well,
_cheap_ if not actually "free"... probably wouldn't take _that_ much effort,
but I'm just guessing. For bonus points, start sharing JSctypes-based wrappers
between the two implementations.

Actually, if you're serious about JS-on-the-server, that's probably just about
the most useful single thing you could possibly do to help it. Well, unless
you're _really_ attached to the JVM...

------
inklesspen
Decent idea, except for the part where you made it an Apache module. If you'd
instead built an app/middleware/server spec like Python's WSGI or Ruby's Rack,
it'd be possible to use this sort of thing with more lightweight servers.

~~~
davidw
Paul Querna is one of the Apache httpd developers, so I think he's quite
likely to go on using Apache, instead of the event based server du jour.

~~~
inklesspen
Well, that's nice for him, but not so nice for us.

~~~
EliAndrewC
If he does decide to pursue this project, probably the most important thing
that will affect whether it gets completed is how useful it is to him and how
much fun he has while doing it. I'd definitely love to see a more generic
system that's not tied to Apache, but I'm fine with him starting off with an
Apache specific setup if that's what gets him motivated and interested.

~~~
davidw
Right - that's how open source works. Scratch your own itch, and work on
things you like. If someone wants to see something not based on Apache, well,
you have the source code, a compiler, and an editor.

Also, Apache is a perfectly fine web server. These event-based things have
been around for a while. I recall moving the images and some other static
assets on linuxcare.com to the Boa web server to save memory. However, Apache
manages to have its own advantages, and stay relevant through the hard work of
people like Paul Querna, even if, no, it's probably not the absolute
fastest/smallest thing out there. Look at Rails - after going through a
succession of various mixes of lighttpd, nginx, mongrel, etc.. etc... it's now
coming back around to Apache and Passenger, and rightly so, Passenger is a
nicer, simpler, more robust way of doing things. Furthermore, in terms of the
other post's "him" and "us", there are a lot more of "him" (Apache users) than
"us" (users of whatever other system).

------
gsmaverick
Awesome stuff, V8 is one of the superior javascript engines and this would be
an amazing step forward.

------
moonpolysoft
Cool. I really think there needs to be a concerted effort to build a standard
library for general purpose javascript that all of the javascript engines will
implement as the standard. It's kind of frustrating that we have this amazing
V8 engine, but no way to use it to do any real work. Older engines have stdlib
projects, but they are tied to the specific implementations.

~~~
randallsquared
A lot of the most useful stuff _has_ to be tied to specific implementations,
if not in API, then in detail. Most of that stuff would be interfaces to non-
javascript libraries.

~~~
wmf
Maybe a common FFI would be a good first step.

~~~
moonpolysoft
Or at least extending the javascript specification to include an API that all
of the engines can implement. I think this is basically the one thing keeping
javascript from entering the mainstream as a general purpose language. As soon
as you can reasonably tell people that their server side javascript will run
on more than one engine, you'll see a lot more development.

