First stab at defining context

[asenchi]

This allows the user to provide a context for their logging across applications without having to define that in various places.

irb(main):002:0> require 'scrolls'
=> true
irb(main):003:0> Scrolls::Log.start
=> true
irb(main):004:0> Scrolls::Log.context({:prefix => "curt"})
=> {:prefix=>"curt"}
irb(main):005:0> Scrolls.log({:test => "data"})
prefix=curt test=data
=> nil

Not that big a fan of the code, I am still thinking about the implementation but posting this for comments.

[dylanegan]

Block support would be nice as you could do

Scrolls::Log.context prefix: "curt" do
  Scrolls.log test: "data"
end

[mmcgrana]

The pattern we've historically used for context like this is a wrapper around the underlying scrolls call that merges in other data:

module Andvari
  module Log
     ...
    def self.log(data, &blk)
      Scrolls.log(merge({app: "andvari", deploy: Config.deploy}, data), &blk)
    end
  end
end

module Andvari
  module GC
    ...
    def self.log(data, &blk)
      Log.log(Log.merge({ns: "gc"}, data), &blk)
    end
  end
end

How does this proposal relate to this practice? More generally, I'm curious what problem exactly this solution is trying to solve.

We've also discussed briefly the idea of using context in a dyamic sense, like:

Scrolls::Log.context(:request_id => "17bc3ba0-8970-11e1-b0c4-0800200c9a66") do
  respond_to_request
end

Not sure how this might relate to the context proposed above.

As usual, I think seeing the code working in production is a good starting point.

[asenchi]

@mmcgrana arguably #context provides a nicer interface than the #merge in your Log module. It might be a small win though, I am not sure. We talked last night about the idea of providing a method for establishing a context/prefix for all logs across an application, such as the request_id in your example. Though I wonder why the current #log method doesn't offer us the same opportunities.

I wasn't sure about the direction I was heading, but adding the ability to handle blocks I think is good. I'll push that change.

Overall, I think the real win of a high level UI for setting a context is that it encourages the user to think about their logging structure that simply putting #log everywhere doesn't offer. I may need to find a clearer way to express that benefit. Perhaps some examples. Ultimately the logging style guide might show the real benefits to thinking about context across usage in an application.