JSGI 0.3

[Heath Matlock]

The JSGI spec hasn't been updated in years. What's required to get it to 1.0? Is there a roadmap somewhere?

[Dean Landolt]

The CommonJS effort has been long abandoned, though some of its efforts have been taken up in various other forums.

JSGI relies heavily on an asynchronous streaming model (forEachables returning promises) that never seemed to gain traction. Now that generators have made their way into the hearts and minds of node devs I wonder if this pattern might be better received. I'd think streams would most important thing to really nail down to firm things up. Years back we kicked around some ideas about how to do backpressure but nothing ever jumped out at me as obviously simple. I wonder what some of these patterns would look like as yield expressions -- that might change the ergonomics quite a bit.

I had a list of outstanding issues lying around somewhere -- if you'd like to take this up I'd be happy to help, but I'm not sure how many users there still are of JSGI servers, and I don't think this group is the place to do this. Perhaps a fork of Kris Kowal's uncommonjs experiment [1] with some working code (and maybe some adapters for popular server frameworks like connect) would be a good place to start.

[1] https://github.com/kriskowal/uncommonjs

On Sun, Jun 16, 2013 at 5:22 PM, Heath Matlock <heathm...@gmail.com> wrote:

The JSGI spec hasn't been updated in years. What's required to get it to 1.0? Is there a roadmap somewhere?

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commonjs+u...@googlegroups.com.
To post to this group, send email to comm...@googlegroups.com.
Visit this group at http://groups.google.com/group/commonjs.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kris Kowal]

First and foremost, I personally do not have time to make the JSGI standard. Take that with a grain of salt, because I also did not have time for Promises/A+, but many hands make light work.

There are several resources from which to start a promise-based JSGI spec.

Q-IO builds HTTP servers and clients using composable decorators (HTTP Apps) and forEachable streams. See "reader", "http", and "http-apps" for implementations, and the corresponding Jasmine specs. The README describes the type signatures of all the involved parts.

http://documentup.com/kriskowal/q-io#http

https://github.com/kriskowal/q-io

Botart is a project by Nathan Stott that uses Q and JSGI for declaring routes.

https://github.com/nrstott/bogart

Joey is a similar project of mine that Motorola was kind enough to open-source. It is also a fluent API for configuring JSGI clients and servers with routes and negotiation.

https://github.com/kriskowal/joey

Also, Michael Jackson started an effort called MachJS based on JSGI and promises. He hoped to enlist Tom Robinson and me to assist with building the specifications there.

https://github.com/machjs/mach

We certainly have enough experts to make a go of it.

As Dean points out, streams and back-pressure were the crux of much argument last time we had a go at this. I am still of the opinion that returning promises from the "write" method of "stream.forEach(write)" provides a great mechanism for signaling when you have finished consuming a bit of content. The Node community has also vetted high- and low-water-level buffering, which I think easily fit the promise/forEach model. By default, streams would pause, emit "write(data)", wait for the returned promise to be fulfilled, then resume. Accounting for "water-level", such a stream would down a semaphore on write(data) and up the semaphore on the resolution of the returned promise, pausing and resuming based on the number of outstanding promises. Since this would have control-flow implications, I’d elect to make the levels arguments of forEach. But that’s just guesswork at this point. I really need to revisit Q-IO in light of the changes to streams in Node.

Kris Kowal

[Michael Jackson]

Thanks for the mention Kris. I just wanted to chime in with a bit of context in case anyone is interested in taking a look at mach.

mach is a project that I started last Fall over lunch with Tom Robinson. As you know he has put a lot of work into JSGI. I've also done quite a bit of work in a similar vein with strata, a callback-based JSGI clone for node. After running the projects in parallel for a while I contacted him to see if he was interested in working together on something new that would combine the best ideas from both of our experience. We agreed to base the whole API around promises. Tom suggested we invite Kris to collaborate as well since he's done a ton of work with Q and Q-http.

So we batted around some ideas on the GitHub issue tracker for a while but never closed them. I myself decided to start writing code to test out some of the ideas we had. It felt pretty good, so I just kept going. Fast forward to today and it's actually a pretty capable little web server. It supports most of the stuff you'd expect, and even a few nice extras like full-blown multipart parsing, streaming file uploads to network storage, and various session storage backends. The README is outdated, but I've been adding stuff to the wiki as I get the time. There are some good pages there. Test coverage isn't bad either.

Node is the only supported platform atm, but other platforms certainly could be supported if you need them. Many of the platform-specific functions are exported by the utils module, which could possibly be swapped out for a utils-rhino module, for example. The index module in particular is designed to be flexible. There is a standard Request object that normalizes node's ServerRequest object and could easily be adapted to other platforms. Responses are plain JavaScript objects with status, headers, and content properties. All content objects, both incoming and outgoing, are currently readable node streams. But really any object that emits "data" and "end" events could conform to the same API.

I'm currently using it in a production website with smallish traffic and really enjoying it. The consistent use of promises throughout the stack make it really easy to do cool things like "catch"ing errors that are thrown from deep within the stack. This is essentially equivalent to Sinatra's halt method, but in a fully asynchronous environment.

Anyway, please check it out if you feel so inclined. I'd love to get some more eyes on it and see if we could evolve it into something more than any one of us could accomplish with his/her own limited amount of free time. :) I'm not married to the API, although I do think certain parts of it are pretty good already. I'd love to get back to the spec soon and formalize some of this stuff. I guess I'm just the kind of person who likes to test something out and make sure it's good before formalizing it into a spec document.

If you have any questions, please don't hesitate to ask. I love to talk about this stuff. :)

[Nathan Stott]

Bogart is still being actively developed. It is used by a small but growing community of developers trying to mesh "the right way" and "the practical way" to create apps now using node.js and promises. My company and a handful of freelancers have sites and tools in production based on Bogart.

--

[Nathan Stott]

I hit enter too soon :).

Bogart has veered away from strict JSGI. There is default middleware that adapts streams and buffers placed in the 'body' to forEachables. It is on my roadmap to replace Kris Zyps JSGI adapter that Bogart depends on to use node.js streams at the lowest level to avoid the need to adapt node.js streams to forEachables.

I am interested in taking Bogart the direction of Q Streams for the body property.

JSGI doesn't need to be standardized any further until we have more implementations that are widely in use. Bogart now interprets the JSGI spec loosely and will continue to interpret it as such for the foreseeable future.