{"_id":"kapp","_rev":"53-c714b0d1a943401cfc50f84479602274","name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","dist-tags":{"latest":"0.3.0"},"versions":{"0.0.1":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.0.1","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","underscore":"1.3.x"},"devDependencies":{"mocha":"1.4.x","request":"2.11.x","restify":"1.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application:\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"../kapp\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', app.handlers.hello);\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nTo be completed.","_id":"kapp@0.0.1","dist":{"shasum":"129d08a14769b82ea5d99200a26a5bbeb316144e","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.0.1.tgz","integrity":"sha512-gzQgD8p0x/b0vIjnwXnNYX5i4BsIs6Me9YChnTlx85KmXR5Z8uQiQmIOtV92Sl/bJwUjlPaozfTATeGK6B3NUw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFIHb9LSEKBrTVfr4x2kUbqyvaLhgSpNT1EBQv+xJVK1AiBi8RBqEdOmdvc78xn55/45RgU7CGUYhWuHfS122AJ+ig=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.0.2":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.0.2","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","underscore":"1.3.x"},"devDependencies":{"mocha":"1.4.x","request":"2.11.x","restify":"1.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application:\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"../kapp\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', app.handlers.hello);\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nTo be completed.","_id":"kapp@0.0.2","dist":{"shasum":"51a7238225dc4a2f2d5bb5848a4ed79cd9561597","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.0.2.tgz","integrity":"sha512-1t4NUn8e4yWZgn/pWXdrbWUUT5qKOnXdzjmPHZiV8QnhMndewzZbz6+QNlAHrrKjCd986SU+j4YDFovSHGyRqw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC5WXZeohqS+ANZGAZEYdRlQTfVWE6s97RARZCXQOjgGAIhAMKJWZdPZcbJIRSJhXxSK7Kdx3sL7dOKRSiTmMiu81xG"}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.0":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.0","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","underscore":"1.3.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application:\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.0","dist":{"shasum":"e99f7c5ef070980c421ec4d38fc38c3e79320420","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.0.tgz","integrity":"sha512-EwVe6ClNh0vESYbInCak2mSzRrmmjdGH15FXo0Z/23L7YfRGfcORehKO5X8vNM+sRIwMWbgnbZGmbCofo23l9Q==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCOGnmeJC0P8pleiIIABVPEVVlE/f1/h7oRZmvZsvJv6AIhAMyiWWwLYjwUqfKcoVvebrCgSx6eQoDQk9emnSGipRHY"}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.1":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.1","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.1","dist":{"shasum":"fc240a4cf3367578d913e7ac355fc6f48bf12e6d","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.1.tgz","integrity":"sha512-zWQrPrxMMLjEMYwyP+heo1kcQ+roMdS4R0ygIl055zmS915J4+GfDetr40D/rhvg2cIAGsLGNw6oSz5oKonWkA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICobPTsgvPfYzXZUx06Ybl5h7n2aqCCDJQjzqS4noZBSAiBydr9DZ9FXD6a2Aq9JDYGOy8vFgO+TNO6a0crPqF6OMA=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.2":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.2","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.2","dist":{"shasum":"cde255b4c0a9180585fedef48ff0149cb9186f35","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.2.tgz","integrity":"sha512-szARNnwGUamyCFTZXk5V4yXqzviAHfKNOI+uw1+QLQ5C0P5C9FwKRQDet1M3JT/3mz+2abHtdDyARczcg1eQzw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCT13iV8PKsS1RhGKEnF+CAtOSrtSy5DFbmCnlcEZLdOgIhAOwkF9R2Y9FM1xPns+QeIVzGY30FWpBx4otcAMusU1an"}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.3":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.3","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","bunyan":"0.14.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.3","dist":{"shasum":"ba8bd156c2a5ac363886e5633e9d5c7481e41b73","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.3.tgz","integrity":"sha512-ZRcE6zFS/o047mORbJNZ1NsAyssCtYaZg3Taj7uq633b0GUG/rzert8R5Dm6KbudH1h2RaG4CjEUmBQO5vGvEA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIB2qpTb4Ilmlen8WWPQHgoDoPIuwiqIaL5y9u5RTPva9AiEAynVAmP0LmnG2yRtgHf1ajn0v7W7xGEz3K8uLsObcurI="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.4":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.4","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","bunyan":"0.14.x","clarity":"*","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.4","dist":{"shasum":"64981f8b5d3576c8ce63bb1f84476d0fee86c577","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.4.tgz","integrity":"sha512-IfQ3VsSik8+zJhqRVREod8vn/O41gggsve9P3Wj0wVNSOQLQE01v6Gl83IDaC16uSYnKJ4SymXYMe8MJQmgJiw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQC//xpUWjxcqpDpg/dRCF6UrDeuo9GNexMDizgo6QPLrwIgAgaaxLaqGRJaV/6kGLU/EI5QlRW3VijvJ/fsd73eas8="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.7":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.7","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","bunyan":"0.14.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.7","dist":{"shasum":"cd0c344aa8d572b0a48092ba8ad33ca4252eddce","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.7.tgz","integrity":"sha512-ICbWTdoCN9WQQ21gAhueYImY9o9T7EZz1+2cpBbC9OB2qpOxggbvSbvws6m5oo7LKvoDSUje+M4jqHkoay0mqg==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEauislhc731/BLmtTa+O6sTL7C8DQVcXnj10A5TWqTWAiBYxH9dxF4bKJVRt2lCAxxmqBZXrUBLLxLDXQe9cBWI8g=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.9":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.9","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","bunyan":"0.14.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.9","dist":{"shasum":"30e5acc9f778f7368558b36e5429cf29cef68ae0","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.9.tgz","integrity":"sha512-AZ55JZViJFTs8xuhCXVxCVJCLHnmpXVOWiUf3TcahKlxuxYDLuXnspAd5/kIQ6DhQ9u4dclGfINS9axeNXni3Q==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIExx3ogGg4hzlvwpxTPKWBqZXsjQg469wAGPht03bY+6AiBPUIBU+Cg16U8Yttgz6bcMFqNSdIPaCwdbm8NLugI9Yg=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.10":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.10","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.10","dist":{"shasum":"9f65f8aa6e1d42f16215913aca0910921bc29e3d","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.10.tgz","integrity":"sha512-TtTgfmh6LBXH12aC7BIlX1mGvAuxFsfUf8iLYFojMUqIbPbXHtrInp6G96GG/d3ReW+re4Q+92YNp7Q8qcBjjw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDxy2u38yDt7yd3hZ+V3IJXsWszKNNJhlHij13JQIlpSQIgUiALG5T3SbdEaWle/Xv7U+MILtrq8yuflf2ozK9tLH0="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.11":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.11","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.11","dist":{"shasum":"d5b69a1fb618d06c5b45615acbd0904d4862860b","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.11.tgz","integrity":"sha512-axQifhdDG5diGJtzzm90njWoSzSpY3Ww3TSWlRSOUVIm30NW1LVyztlT+4tEnO18lpL7owdhMQpl6rbx4F65Gg==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIAHEOpflWmoBX4cYOtFKW3uJFSMy3BbWDgiQDZWxDTgXAiBQ6PAEuJc/KC+9QITIECv0zbWBJ/vTxQ4yKkdeLSbTsA=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.12":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.12","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allowPublic();\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.12","dist":{"shasum":"5192882d58ddf48e2fca7e107ec7f40713e727b5","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.12.tgz","integrity":"sha512-H2jKa+1YE4D8SNJAoq8Si+In+wUU6WxR/ipmZgQ/n7bTB3MwH+kvIFHMx06VlEGSLCSDR78X2V7cJT9khcUqSA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIH5BmzQulS66nTCxojlD9QsZXl1cJ2hl+hT367Go1IPgAiAFPVm4SyrXF5sComEwVfktDo/eC6oE+5JUW6p4i3ZMEQ=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.13":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.13","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allowPublic();\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.13","dist":{"shasum":"c2ee3de281fea35be6c4cfea98c9bd2a778bed2f","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.13.tgz","integrity":"sha512-lT7nAyh9vwLLjDj3iEEaASpEA0btwPIpvIIH2d/muTtHoB1e6TkuDD7SMNe+fVuLE41A/Zxjxpu+MDEqUapkRA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDwzAa7mTSYsz82dtIBnYaduHxPnDcQdXKVUQRX+/mf0AiEAv2/9Pa07PiMvWHWxFcwMpf5yEUwZaqwpY76oYubU3kk="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.14":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.14","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","follow":"git://github.com/DamonOehlman/follow.git","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allowPublic();\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.14","dist":{"shasum":"032c1f9af6112894e5fcb976ff467d73cf5dc0ad","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.14.tgz","integrity":"sha512-NJhGgkmFDGSLG6R2V5tBn8j92eu7OiobudCdHLOJDiN7JqBcT/iwSCnE/cdQ2UBTU5fc9UpWXqYWINp/WU8Y1Q==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCICTiCd0t1hD7/+FLHcpykcdQmbbMrJPga3Nma3OXNvzYAiEAuI198/niF6waq/epUa4SXLJXfrYD4UuZjmUAnc6Hp/Q="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.1.15":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.1.15","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","follow":"git://github.com/DamonOehlman/follow.git","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allowPublic();\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.1.15","dist":{"shasum":"a07eee19833680d3bf90033f1ba15bafbf9ab4db","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.1.15.tgz","integrity":"sha512-3CsxS579vrzAhkUZ4VGCsg7ptHkcIUrSC5yN6cLal6v0Z9S0f+fpYWqvBf39wFpg1AA05PrfC2Ieae7MaEmKzw==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIGWdizilxZi89UA9ycBHADh7i/LEMm4AFRmFEtjtEKdsAiA1ipynKnMjuFNpC1u0d+KHzOHa+//ful8mk57p+vE+wg=="}]},"_npmVersion":"1.1.52","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"},"directories":{}},"0.2.0":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.2.0","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","follow":"git://github.com/DamonOehlman/follow.git","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"0.4.x"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allow('public');\n```\n\n### Specifying User Accessibly Routes\n\nTo define a route that can be accessed directly from the Kondoot frontend (as opposed to through other applications), you need to define the route as `allow('user')`.  If you accidently type `users` that's ok too:\n\n```js\napp.server.get('/frontend-ok', function(req, res) {\n  res.end('Hi');\n}).allow('user');\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.2.0","dist":{"shasum":"3c497cfdca314418f8ba2d5f67ed00ac8249b81f","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.2.0.tgz","integrity":"sha512-/sgw39RZN+Bsk2B3oM0YyQb0VQ+YSsHbecSZbBRVNPo7TF8HaR15eYUVcXQhC7wNHQnWphRyOp22qONb69pVnQ==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFCiqvuPlYwFvFiWSxfJeSl4pZxmUpINWsASs0BY6Sy0AiBk/sLX5JCQZl7JuJG0OnlM53Z6sSBtKMfgzArd9Z8Fbw=="}]},"_npmVersion":"1.1.62","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}},"0.2.1":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.2.1","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","seaport":"0.8.x","follow":"git://github.com/DamonOehlman/follow.git","sharedconfig":"0.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.4.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"~0.5.0"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allow('public');\n```\n\n### Specifying User Accessibly Routes\n\nTo define a route that can be accessed directly from the Kondoot frontend (as opposed to through other applications), you need to define the route as `allow('user')`.  If you accidently type `users` that's ok too:\n\n```js\napp.server.get('/frontend-ok', function(req, res) {\n  res.end('Hi');\n}).allow('user');\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.2.1","dist":{"shasum":"85663ca774cf990d4998f95a97a5de362a5cb964","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.2.1.tgz","integrity":"sha512-cAsZuev6W87y7XLMHyzIIhM8FwOozHhdYPeL79wKHS3g4yHwrRqJbNbNBlAlwzdUsZpmNCIYG4znSMDJH/dQcA==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDwn4BEwyTH0n5kO1xYytA4Awep3z09Z2cMwkQfQH2TyAiEAknjjFcmeOOPBZuJPsj+v/yfOLdaKBWonB2ir5fanbpU="}]},"_npmVersion":"1.1.62","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}},"0.2.2":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.2.2","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","kconf":"0.1.x","seaport":"0.8.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.6.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"~0.5.0"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allow('public');\n```\n\n### Specifying User Accessibly Routes\n\nTo define a route that can be accessed directly from the Kondoot frontend (as opposed to through other applications), you need to define the route as `allow('user')`.  If you accidently type `users` that's ok too:\n\n```js\napp.server.get('/frontend-ok', function(req, res) {\n  res.end('Hi');\n}).allow('user');\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.2.2","dist":{"shasum":"4ee2860642ce10662cf4793ba3c708a7399b7d53","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.2.2.tgz","integrity":"sha512-Ywk0uI4HARdgZZnicjBx08+aw12+Be5LSPXcy1BqC+pWFp2LL9gr2t5wsLWQBd1MJ3imEQXUlR7Gjo9KReqbJg==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDz3vIysWdsP1pSsMWTk7BIS/TwXMSi/lUBikuOFRzIeQIgVT6Ht+sW7f+j56JLDYghBe0DUvDFwlrsPDf9yvjufbM="}]},"_npmVersion":"1.1.62","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}},"0.3.0":{"name":"kapp","description":"Kondoot Application Wrapper - the baseline wrapper for building distributed, centrally managed apps at Kondoot","author":{"name":"Kondoot","email":"development@kondoot.com"},"maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"tags":["build"],"version":"0.3.0","engines":{"node":">= 0.6.x < 0.9.0"},"dependencies":{"async":"0.1.x","clarity":"*","cookies":"0.3.x","debug":"*","eventemitter2":"0.4.x","kconf":"0.1.x","seaport":"1.1.x","lodash":"0.7.x","winston":"0.6.x","winston-syslog":"0.2.x"},"devDependencies":{"mocha":"1.6.x","monk":"0.3.x","request":"2.11.x","restify":"1.4.x","tako":"0.3.x","testrest":"~0.5.0"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"},"bugs":{"url":"http://github.com/kondoot/kapp/issues"},"scripts":{"test":"./node_modules/.bin/mocha --reporter spec --timeout 30000"},"contributors":[],"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application (assuming that you want to use restify):\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"0.1.x\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\nIf you are using a different server framework, then remove the dependeny on restify.\n\n## A Simple Application (using a Mongo Backend)\n\n```js\nvar app = require('kapp')('mongo-example', {\n      beforeReady: [ connectDB ]\n    });\n\nfunction connectDB() {\n  app.db = require('monk')(app.config.mongo);\n}\n\napp.start(function(err) {\n  // if we encounted an error, then report it\n  if (err) return;\n\n  // bind handlers\n\n  // handle mongo configuration changes\n  app.config.on('update.mongo', connectDB);\n});\n```\n\n__NOTE__: If the kapp is running in a \"seaport enabled\" environment then the \n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', function(req, res, next) {\n    });\n});\n```\n\n## Authentication\n\nBy default, a KApp expects valid user credentials when serving a request.  Valid credentials can either be in the form of: \n\n- a user header (`x-kondoot-user`) and basic auth, or;\n- through a session details populated by rails (stored in the `_kondoot_session` cookie).\n\nFor example, when registering a handler such as the one shown below, if no authentication information is provided, then the KApp will generate a `401` header without you needing to take any specific action:\n\n```js\napp.server.get('/me', function(req, res) {\n  res.end('User: ' + req.userid);\n});\n```\n\nYou may notice in the code above that a user's ID can be accessed, through the request object (`req.userid`).  In the case of unauthenticated requests this will be set to -1.\n\n### Specifying Publicly Accessible Routes\n\nTo define a route and handler that does not require user authentication, we must define a route as public by using the `allowPublic()` method that KApp patches in to restify's native `Route` class:\n\n```js\napp.server.get('/public', function(req, res) {\n  res.end('Hi');\n}).allow('public');\n```\n\n### Specifying User Accessibly Routes\n\nTo define a route that can be accessed directly from the Kondoot frontend (as opposed to through other applications), you need to define the route as `allow('user')`.  If you accidently type `users` that's ok too:\n\n```js\napp.server.get('/frontend-ok', function(req, res) {\n  res.end('Hi');\n}).allow('user');\n```\n\n## Logging in a KApp\n\nKApps use [winston](https://github.com/flatiron/winston) for logging by default.  While various options for logging were investigated, Winston provides flexible configuration and a wide variety of logging transports.  Configuration for logging is set in the [distrbuted configuration files](https://github.com/kondoot/kondoot-config/tree/master/distributed).\n\nAccess to the logger is provided through the application instance, using the `logger` member.  For instance, to log a warning the following code could be used:\n\n```js\napp.logger.warn('That was unexpected');\n```\n\nOr more generically using log:\n\n```js\napp.logger.log('warn', 'That was unexpected');\n```\n\nDuring the logging initialization phases, a KApp is configured to use syslog logging levels defined by winston:\n\n```\n- debug   (0)\n- info    (1)\n- notice  (2)\n- warning (3)\n- error   (4)\n- crit    (5)\n- alert   (6)\n- emerg   (7)\n```\n\n__NOTE__: Using syslog levels the function is `warning` not `warn`.  That said, the KApp initialization binds a helper from `warn` to `warning` to stop you getting in to trouble.\n\nThe default logging configuration that is used routes log messages of error and above to the console, and messages of warn and able to syslog (which is then passed on to [loggly](http://loggly.com/) for aggregration).  Additional log profiles of `info` and `debug` are also available to which will put your application into more verbose logging modes.  This can be programmatically enabled in an application:\n\n```js\napp.useLogLevel('debug');\n```\n\nOr through making updates to the centralized configuration section `log-overrides` which specify the hostname of the machine you wish to configure to use a logging scheme other than the default scheme.\n\n## Advanced: Using a server framework other than RESTify\n\nIf restify isn't your favourite framework, then you can easily implement an alternative by providing a `createServer` function for the `kapp` creation opts.  A few examples of implementations for specific frameworks are shown below:\n\n### Tako\n\n<https://github.com/mikeal/tako>\n\n```js\nvar tako = require('tako')\n  , app;\n\n// initialise the app\nmodule.exports = app = require('../')('tako-example', {\n  createServer: function() {\n    var server = tako();\n\n    // tako exposes the listen interface through httpServer and httpsServer\n    // expose the appropriate one through a bound handler\n    server.listen = server.httpServer.listen.bind(server.httpServer);\n\n    // return the server instance\n    return server;\n  }\n});\n\n// start the application and create the routes\napp.start(function(err) {\n  if (err) return;\n\n  app.server.route('/hello').json({ name: 'Bob' });\n});\n```","_id":"kapp@0.3.0","dist":{"shasum":"7d3ad96f18827d01e973321b6a4a25c925d17e7e","tarball":"https://registry.npmjs.org/kapp/-/kapp-0.3.0.tgz","integrity":"sha512-LkV1JIEgTIjTp/+MzKZhNSdH+kxk7cxogc5FmzUlCFI4lN78iMYPs+T1S5+J6DILhd4bFA/rGLmHYJKZHbWw/w==","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC44LLzXXlqJH95H9U2qectKerVGRRX12XuakVrIfKGUAIhAMQ0okgfA85O5yJebqenpHViNu+W3N3WS/RT1+RLXXuC"}]},"_npmVersion":"1.1.62","_npmUser":{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}}},"readme":"# Kondoot Application Template (Kapp)\n\nThis repository is designed to make the process of creating node applications that fit into the stack used at Kondoot super simple and repeatable.\n\n## Creating a Kapp\n\nCreating a Kapp is very simple, and basic initialization goes as follows:\n\n```js\nvar app = require('kapp')('appname');\n```\n\nOptions can be specified that influence how a Kapp behaves, and these are covered in more detail later. Once you have completed your application specific initializations you then call `app.start()` to get the application to load handlers, configuration information, start the default application server ([restify](https://github.com/mcavage/node-restify) is used by default), etc.\n\nWhen the application is ready and serving requests it will fire the `ready` event, and if the `app.start()` call is supplied a callback that will be called shortly after the ready event is triggered.\n\n### Baseline package.json for a Kapp\n\nThe following represents a baseline `package.json` file that should be used to create new a new Kondoot node application:\n\n```json\n{\n  \"name\": \"appname\",\n  \"description\": \"Application Description\",\n  \"author\": \"Kondoot <development@kondoot.com>\",\n  \"tags\": [\n    \"build\"\n  ],\n  \"version\": \"0.0.0\",\n  \"engines\": {\n    \"node\": \">= 0.6.x < 0.9.0\"\n  },\n  \"dependencies\": {\n    \"kapp\": \"../kapp\",\n    \"restify\": \"1.4.x\"\n  },\n  \"devDependencies\": {\n  },\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git://github.com/kondoot/appname.git\"\n  },\n  \"bugs\": {\n    \"url\": \"http://github.com/kondoot/appname/issues\"\n  },\n  \"scripts\": {\n    \"test\": \"./node_modules/.bin/mocha --reporter spec --timeout 30000\"\n  },\n  \"contributors\": []\n}\n```\n\n## Handler Loading\n\nOne of the helpful things that Kapp does for you is load route handlers from a `handlers` directory from within your application structure.  For instance consider the following:\n\n```\n- handlers\n|- echo.js\n|- hello.js\n- server.js\n- package.json\n```\n\nIn the case above, during initialization Kapp will have autodiscovered the echo and hello handlers for you and wired them into the handlers object (`app.handlers.echo` and `app.handlers.hello` respectively).  It's important to note however that the handlers are not connected to the server instance in any way as defining route handlers and directing them to the handlers is the responsibility of the application.\n\nIn terms of the actual handler functions, you are essentially implementing handlers that are identical to the application server you are using in your Kapp application (restify by default), __but with a leading `app` argument__ that is injected by Kapp:\n\n```js\n// an example echo handler\nmodule.exports = function(app, req, res, next) {\n    res.end(req.body);\n};\n```\n\nThis app argument will allow you to access your application object within your handlers without having to try and manage messy external references to the object.\n\n### Defining Application Routes\n\nTo specify your application routes, the best time to do this is in response to the `started` event that is emitted by a Kapp:\n\n```js\napp.once('started', function(server) {\n    server.get('/hello', app.handlers.hello);\n});\n```\n\n## Advanced: Using a server framework other than RESTify\n\nTo be completed.","maintainers":[{"name":"damonoehlman","email":"damon.oehlman@sidelab.com"}],"time":{"modified":"2022-06-19T07:51:24.403Z","created":"2012-09-20T00:55:22.154Z","0.0.1":"2012-09-20T00:55:27.466Z","0.0.2":"2012-09-20T05:43:03.457Z","0.1.0":"2012-09-21T06:14:15.414Z","0.1.1":"2012-09-21T06:45:42.417Z","0.1.2":"2012-09-21T07:08:54.927Z","0.1.3":"2012-09-24T03:41:54.753Z","0.1.4":"2012-09-24T05:07:29.993Z","0.1.6":"2012-09-24T08:09:06.997Z","0.1.7":"2012-09-24T09:16:00.063Z","0.1.8":"2012-09-24T09:55:18.758Z","0.1.9":"2012-09-24T10:25:52.401Z","0.1.10":"2012-09-25T06:27:56.286Z","0.1.11":"2012-09-26T04:29:45.849Z","0.1.12":"2012-09-26T04:48:39.338Z","0.1.13":"2012-09-26T06:23:54.805Z","0.1.14":"2012-10-03T02:32:20.547Z","0.1.15":"2012-10-03T06:34:18.123Z","0.1.16":"2012-10-10T06:24:26.605Z","0.2.0":"2012-10-10T06:33:28.945Z","0.2.1":"2012-10-22T01:33:29.058Z","0.2.2":"2012-10-25T00:29:57.158Z","0.3.0":"2012-11-13T07:11:37.771Z"},"author":{"name":"Kondoot","email":"development@kondoot.com"},"repository":{"type":"git","url":"git://github.com/kondoot/kapp.git"}}