We already do the latter in Merb (to skip expensive param processing in production mode) and will be adding it to Rails as well -- it'd be nice to standardize on it.
I have been implementing a similar feature in quite a few of the stacks I've been setting up, and it'd be nice to have a standard in the spec. I would prefer we take the duck typing approach to the entry rather than the type restraint, as long as the object supports the 5 methods (and possibly #level for introspective purposes) it would be a valid rack.logger value.
stadik.net
On Jul 27, 2009 12:12 PM, "Yehuda Katz" <wyc...@gmail.com> wrote:
I'd like to suggest that a standard Ruby logger object be found in env["rack.logger"]. This logger object should support:
We already do the latter in Merb (to skip expensive param processing in production mode) and will be adding it to Rails as well -- it'd be nice to standardize on it.
We should require servers to set a default logger so its *always* available. Then Rails or other middleware down the stack can swap it out with something else.
On Tue, Jul 28, 2009 at 6:02 AM, Joshua Peek <j...@joshpeek.com> wrote:
> +1
> We should require servers to set a default logger so its *always* > available. Then Rails or other middleware down the stack can swap it > out with something else.
I would argue against a formal logger being required, but generating a default of a wrapper around rack.error seems sufficient enough a default.
-- stadik.net
On Jul 27, 2009 1:07 PM, "Joshua Peek" <j...@joshpeek.com> wrote:
+1
We should require servers to set a default logger so its *always* available. Then Rails or other middleware down the stack can swap it out with something else.
On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scyt...@gmail.com> wrote: > I would argue against a formal logger being required, but generating a > default of a wrapper around rack.error seems sufficient enough a default.
Thats a good idea.
I just want something to be in rack.logger so we don't have to nil check and you can count on your message going somewhere.
> We should require servers to set a default logger so its *always* > available. Then Rails or other middleware down the stack can swap it > out with something else.
Joshua Peek <j...@joshpeek.com> writes: > On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scyt...@gmail.com> wrote: >> I would argue against a formal logger being required, but generating a >> default of a wrapper around rack.error seems sufficient enough a default.
> Thats a good idea.
> I just want something to be in rack.logger so we don't have to nil > check and you can count on your message going somewhere.
>> On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scyt...@gmail.com >> > wrote: >>> I would argue against a formal logger being required, but >>> generating a >>> default of a wrapper around rack.error seems sufficient enough a >>> default.
>> Thats a good idea.
>> I just want something to be in rack.logger so we don't have to nil >> check and you can count on your message going somewhere.
+1, however, I would request please that some form of Null / No-Op logger is available in core for profile testing (IO sucks).
The 'deferred' spec I find harder to agree with off the bat, as I think it needs to be registered somewhere in the stack, or heavily coupled.
I have some questions, as a result (particularly to Yehuda):
* Who implements the scheduling? * Who implements the running? * When is it run? (as per some spec definition) * Does it have to be the same process?
I'd envisage something along the lines of:
l = Rack::SyncLogger.new l.info { .. happens immediately .. }
l = Merb::Logger.new l.info { .. happens after the request .. }
l = Rack::NullLogger.new l.info { .. happens immediately or after request ? .. }
>>> On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scyt...@gmail.com> >>> wrote:
>>>> I would argue against a formal logger being required, but generating a >>>> default of a wrapper around rack.error seems sufficient enough a >>>> default.
>>> Thats a good idea.
>>> I just want something to be in rack.logger so we don't have to nil >>> check and you can count on your message going somewhere.
> +1, however, I would request please that some form of Null / No-Op logger is > available in core for profile testing (IO sucks).
> The 'deferred' spec I find harder to agree with off the bat, as I think it > needs to be registered somewhere in the stack, or heavily coupled.
> I have some questions, as a result (particularly to Yehuda):
> * Who implements the scheduling? > * Who implements the running? > * When is it run? (as per some spec definition) > * Does it have to be the same process?
On Mon, Jul 27, 2009 at 2:27 PM, Scytrin dai Kinthra<scyt...@gmail.com> wrote: > I would argue against a formal logger being required, but generating a > default of a wrapper around rack.error seems sufficient enough a default.
Who generates the default wrapper?
And if a middleware alters rack.errors, the default wrapper may break. This is error prone.
On Mon, Jul 27, 2009 at 1:02 PM, Joshua Peek<j...@joshpeek.com> wrote:
> +1
> We should require servers to set a default logger so its *always* > available. Then Rails or other middleware down the stack can swap it > out with something else.
A little pushback: I dislike the trend of requiring more from the environment for convenience. It's nice to rely on for a framework, but it makes ad-hoc usage painful without an extra tool like MockRequest.
Having to tack on a superfluous { 'rack.input' => StringIO.new } was bad enough. I feel like we're robbing Rack of some of its agility.
Jeremy Kemper wrote: > On Mon, Jul 27, 2009 at 1:02 PM, Joshua Peek<j...@joshpeek.com> wrote:
>> +1
>> We should require servers to set a default logger so its *always* >> available. Then Rails or other middleware down the stack can swap it >> out with something else.
> A little pushback: I dislike the trend of requiring more from the > environment for convenience. It's nice to rely on for a framework, but > it makes ad-hoc usage painful without an extra tool like MockRequest.
> Having to tack on a superfluous { 'rack.input' => StringIO.new } was > bad enough. I feel like we're robbing Rack of some of its agility.
