When you say “another component in the project” do you mean logging services project or log4j? I’d prefer to see you do this in a separate repo or at least a branch until we understand what it looks like. If it is going to apply to many things it probably makes sense to be a separate repo.
Ralph > On Oct 19, 2017, at 8:26 AM, Matt Sicker <boa...@gmail.com> wrote: > > For generic structured records, I'd probably go with Avro or Thrift since > LogEvents have a lot of standard fields with only a few optional map-like > structures. For optimized log appending, the binary format was proposed as > a way to append quickly and without garbage IIRC. > > On 19 October 2017 at 10:21, Gary Gregory <garydgreg...@gmail.com> wrote: > >> What about BSON? >> >> Gary >> >> On Oct 19, 2017 08:41, "Matt Sicker" <boa...@gmail.com> wrote: >> >>> I don't have the ticket on hand, but a few months ago, Remko suggested a >>> binary logging format that would allow for super fast appends of >>> log-specific information along with companion files for additional >> metadata >>> not commonly used in log messages. I've been thinking about this idea a >> bit >>> in relation to existing structured layouts (both textual and binary), >> and I >>> was thinking that it might be a useful format to standardize on for all >> the >>> logging projects. >>> >>> What I'd like to propose is making another component in the project that >>> would contain a reference implementation of encoding and decoding the >>> format in Java, C++, .NET, and PHP (or as a C binding for PHP). >>> Potentially, this format could be inclusive with other logging projects >>> like Logstash, Logback, Splunk, etc. >>> >>> What do you all think? Is this a good idea? Or would this be duplicating >>> effort from other standards already? >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >> > > > > -- > Matt Sicker <boa...@gmail.com>
