On Jun 15, 2013, at 8:46 AM, Christopher Armstrong email@example.com wrote:
Yeah... I feel like a lot of the things you say in this email aren't related to the point I was trying to get across, which was the interface and effect, not the implementation of it.
Even if it's not really what you'd intended, I think it's pretty good to keep discussing these issues (avoiding unnecessary formatting, putting the right responsibilities in the right place).
I also assume that developers will be able to hook up additional observers to save out .concatenated-json files, or stream to some network protocol, or whatever.
To reiterate a little from my previous reply, I think we should be, as much as possible, moving to make that the default. Now, actually making it the default is a pretty disruptive change, but I think we could get as far as "implement the feature at all" before anyone would start complaining ;).
In other words, every developer should not have to realize they should write a JSON(ish) emitter and figure out how to get that to work on their own; we should just provide one that does the right thing.
To dial this back to what we actually need to talk about in the proposed log system, the issue is mostly to do with
I can implement the UUID thing as a completely separate ticket and we can discuss it on its own merits; meanwhile, you can happily add log IDs to everything in your applications. I'd be quite happy to table this part of the conversation for a separate ticket; I just thought it would be a nice thing that could fall out of some of the other parts of a new logging system.
Yeah, I'm sorry that this has gotten so much scope-creep.
No problem. This is all good stuff to talk about; we don't discuss operational concerns of managing Twisted services (either server *or* client side) nearly often enough on this list. I wish we had more discussions like this!
I'll reiterate that I think redoing what I've been speaking about as the "system" key is most important (but maybe it should be called something other than "system", since you've clarified what its intent was in another email).
Well, "system" was a pretty horrible name for the thing satisfying that intent. We have "log_namespace" in the new logging system, and I think that (in combination with an idiomatic "log_id", that only needs to be unique within that namespace) you could get more or less what you want.
I think we're going to drop the "system" key entirely (except in the contexts where it's required for compatibility, of course). Jean-Paul's recent comment in the quote file is apropos.