HORIZON PROJECT

# higher prio

- `bunyan` (without redir) ^C should stop, doesn't since recent change

- man page for the bunyan CLI (refer to it in the readme)

    - perhaps wait for a bunyan new version with deps, and use dashdash

      with a (vapour) man page generator

# v2

- ^C fix

- node-exeunt

- `createLogger(<config-and-fields>, <fields>)` changes (#460)

    - see section below

- the dtrace-provider thing (#487)

    TODO: answer Cody email

- use package.json version for VERSION

- use deps

    - dashdash

    - assert-plus?

    - verror?

- break out to multiple files

    - want to work through PRs before that, so don't just break them all

- TODO: a quick pass through tickets and pulls for other things to include

- get ticket refs for the above, if any

- formatters: read up again on `glp master..1.x`

- support for customer formatters

    - for the CLI as well? How? ~/.bunyanrc?

# changes to ctor and log.child to separate fields from config

<https://github.com/trentm/node-bunyan/issues/460>

Current:

    createLogger(<config-and-fields>)

    log.child(<config-and-fields>, <just-fields-bool>)

Could be:

    createLogger(<config-and-fields>, <fields>)

    log.child(<config-and-fields>, <fields>)

        # Still support: log.child(<config-and-fields>, <just-fields-bool>)

Pros: Compat issues are minimal: a change is only required if there is a

collision with used field and a new config var name.

Cons: A *slight* con is that my guess is the common usage of child is

`log.child(<fields>)`, so the more future-proof common usage becomes:

    log.child(null, <fields>)

That's not too bad. It is clearer at least than:

    log.child(<fields>, true)

TODO:

- is there a ticket for this work already?

- make the change

- do a migration guide? i.e. provide the grep commands to find all

  possible calls to inspect. E.g. if don't have `rg logUndefined` in your

  code, then you are fine. And one time future-proofing via changing

  to fields in the *second* arg.

- list of issues/pulls that wanted to add new config fields

# docs

- document log.addStream() and log.addSerializers()

# someday/maybe

- 2.0 (?) with `v: 1` in log records. Fwd/bwd compat in `bunyan` CLI

- `tail -f`-like support

- full-on docs

- better examples/

- better coloring

- look at pino (bunyan style, perf benefits)

- would be exciting to have bunyan support in http://lnav.org/ if that

  made sense

- "template" support for 'rotating-file' stream to get dated rolled files

- "all" or "off" levels? log4j? logging.py?

  logging.py has NOTSET === 0. I think that is only needed/used for

  multi-level hierarchical effective level.

- buffered writes to increase speed:

    - I'd start with a tools/timeoutput.js for some numbers to compare

      before/after. Sustained high output to a file.

    - perhaps this would be a "buffered: true" option on the stream object

    - then wrap the "stream" with a local class that handles the buffering

    - to finish this, need the 'log.close' and `process.on('exit', ...)`

      work that Trent has started.

- "canWrite" handling for full streams. Need to buffer a la log4js

- test file log with logadm rotation: does it handle that?

- test suite:

    - test for a cloned logger double-`stream.end()` causing problems.

      Perhaps the "closeOnExit" for existing streams should be false for

      clones.

    - test that a `log.clone(...)` adding a new field matching a serializer

      works *and* that an existing field in the parent is not *re-serialized*.

- split out `bunyan` cli to a "bunyan" or "bunyan-reader" or "node-bunyan-reader"

  as the basis for tools to consume bunyan logs. It can grow indep of node-bunyan

  for generating the logs.

  It would take a Bunyan log record object and be expected to emit it.

        node-bunyan-reader

            .createReadStream(path, [options]) ?

- coloring bug: in less the indented extra info lines only have the first

  line colored. Do we need the ANSI char on *each* line? That'll be

  slower.

- document "well-known" keys from bunyan CLI p.o.v.. Add "client_req".

- More `bunyan` output formats and filtering features.

- Think about a bunyan dashboard that supports organizing and viewing logs

  from multiple hosts and services.

- doc the restify RequestCaptureStream usage of RingBuffer. Great example.

- A vim plugin (a la http://vim.cybermirror.org/runtime/autoload/zip.vim ?) to

  allow browsing (read-only) a bunyan log in rendered form.

- Some speed comparisons with others to get a feel for Bunyan's speed.

- what about promoting 'latency' field and making that easier?

- `log.close` to close streams and shutdown and `this.closed`

  process.on('exit', log.close)

  -> 'end' for the name

- bunyan cli: more layouts (http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/EnhancedPatternLayout.html)

  Custom log formats (in config file? in '-f' arg) using printf or hogan.js

  or whatever. Dap wants field width control for lining up. Hogan.js is

  probably overkill for this.

- loggly example using raw streams, hook.io?, whatever.

- serializer support:

    - restify-server.js example -> restifyReq ? or have `req` detect that.

      That is nicer for the "use all standard ones". *Does* restify req

      have anything special?

    - differential HTTP *client* req/res with *server* req/res.

- statsd stream? http://codeascraft.etsy.com/2011/02/15/measure-anything-measure-everything/

  Think about it.

- web ui. Ideas: http://googlecloudplatform.blogspot.ca/2014/04/a-new-logs-viewer-for-google-cloud.html