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.
-glyph