fab3.js

// thoughts for v3 of the (fab) API.
// 
// each handler gets two function arguments:
// (1) a stream back to the last app, and
// (2) a stream forward to the next app, or a 404 if there is none.
// 
// (i haven't figured out elegant names, so let's just call them respond for and request)
// 
// all information about the request is streamed, so that you need to 
// 
// so you can still do this:

function staticHandler() {
  return "this is a static string that needs no info about the request"
}

// but if you need info about the request, you can send a listener to get it
// and any other subsequent events on the request

function dynamicHandler( respond ) {
  respond( function( obj ) {
    if ( obj.url ) respond( "the url is " + obj.url, null )
  })
}

// i realize this is slightly cumbersome, but you can always add middleware
// that decorates the "respond" function with the original request information,
// and buffers the request so that the API is just like the current one.

// anyway, this means you can do cool stuff like this, a handler that streams back
// info about the request

function echoHandler( respond ) {
  respond( respond );
}

// the idea is that now middleware is just like a handler,
// but receives another app (the next app) as well.
// so the following is middleware that just logs:

function identityMiddleware( respond, request ) {
  require("sys").puts( "identityMiddleware was called" );
  respond( request );
  request( respond );
}

// paths will also be implemented as middleware: they evaluate the current
// pathname, dish out to their (fab) context if it matches, or just pipe out
// to the next path or middleware if they don't.

// this means that the order of execution is much clearer:

require( "fab" )

()

  ( fn1 ) // middleware

  ( "/path1", fn3, fn4 )

  ( fn2 )

  ( "/path2" )
    ( fn3 )
    ( fn4 )
  ()

()

// /path1 and /path2 are identical, but the difference is that the fn2
// middleware only applies to /path2

// comments welcome!