On 03/27/2012 04:29 PM, Botond Botyanszki wrote:
On Tue, 27 Mar 2012 13:07:51 -0700 (PDT) david@lang.hm wrote:
On Tue, 27 Mar 2012, Botond Botyanszki wrote:
On Tue, 27 Mar 2012 12:18:56 -0700 (PDT) david@lang.hm wrote:
I think it would be better to have the serialization format be determined automatically by the library if possible.
One way to do this is to have a handshake.
When a app opens /dev/log, the syslog server sends a capabilities message.
The client can ignore this message and send traditional formatted syslog data to the server
Or, the client can read the capabilities message and then pick which supported format (potentially with compression options) to use to send data to the server.
This approach lets the format be anything that the library supports, under the control of the sysadmin of the system (by configuring what capabilities the syslog daemon advertises) without the application programmer needing to know anything about these formats.
thoughts?
If you want a bidirectional protocol, you should create a new interface for that instead of breaking compatibility with older tools and doing it over the good old /dev/log unix domain socket. But I think this is an overkill if it is only designed to query capabilities locally and not over the network. If the local admin can configure the syslogd, he could surely configure the syslog interface (inside or outside glibc) so that they understand each other. This would be the job of the distro maintainers anyway.
other than recompiling things, how would the sysadmin change the configuration system wide?
There's a significant overhead in searching for a config file and parsing it, so I wouldn't want to go that route.
There are other options too:
- environment variables
This is a bit ugly to require every app to set env variables. This is close to the config file hassle.
- loadable modules
Yes. I want a small module that has one function
const char *syslog_capabilities(void);
that will return a commas separated list of the structured log formats in a priority order: "JSON,XML,XMLT,BSON" or something like. The the library will figure out what format to use base on what it understands.
No config files, no environment varibles. The module comes with syslog implementation. I do not see any drawback in such approach.
Both of these are already used within glibc.
Regards, Botond _______________________________________________ lumberjack-developers mailing list lumberjack-developers@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/lumberjack-developers