----- Original message -----
> 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.

+1

Either just assume that the server supports it or use /dev/slog or something where you can assume support for this. I wouldn't open a negotiation phase unless that's also available on the network which opens the scope considerably: define a new protocol for syslog. wasn't an easy thing with 3164 or 5424 either.

'logger' uses a custom implementation for submitting log messages for example.