On Wed, 28 Mar 2012, Gergely Nagy wrote:
There's one more thing I would like to add, regarding the discussion about handshake and how to change/replace/extend/whatever /dev/log: why care?
I don't think there must be a single interface to get logs from one application to another, nor should we care about the transportation issue, unless in context of libc (but more on that later, in another thread).
Why? Because there's no single size that fits all. We want to be able to *work with* logs, so we need a format, or representation that makes sense, is easy to work with, and is pretty much a standard. How it arrives from the producer to the consumer, is none of our business, in my opinion.
There are a few points where I believe that there needs to be widespread standardization, and the passing of log messages from applications to the system is the most important of them in my opinion.
If this is not standardized, then the result will be that some applications can only write logs to some destinations. This defeats a huge amount of the value of defining standards for logging.
looking at things from a high level, I don't care what the function calls look like that a programmer uses to generate a log message, but I care tremendously about how those functions communicate to a Dispatcher daemon (which will be based on the existing syslog daemons, at least for now since they provide so much of the desired functionality already)
I agree that there will be differing needs. As a result, I believe that there will need to be multiple protocols. (more on this below)
If there are multiple protocols possible, the standard needs to define a few things.
1. what protocols are mandatory
2. how to figure out what protocol is being used
We could just say that JSON is the only mandatory protocol, but I think we do want more than that.
We could just say that it's up to the system administrators and programmers to configure everything to know that the other side is useing, but if we do that we will have justly earned the hate of system administrators for life (and beyond), especially if changing the sending protocol requires changes to the openlog call in the application.
I'm not saying that we have to define all the possible protocols now, but we have some ideas of a few that we want to do, so we should start with them and think about how we would add others.
As for what protocols are desirable, we have
JSON simple, human readable, works without any changes to existing log mechanisms
XML human readable, supports data types, message types, strong mindshare in the fields of structured data. many existing tools
BSON relativly simple, more efficient than human readable text in some cases, supports data types
David Lang