Hello,
My concerns are the same what Gergely expressed below, thanks for taking
the time to write this.
Other than that, the field list at
contains
appname and app!name (app.name to put it right;). Same with proc and
possibly others. This is ambiguous, or I'm not understanding something.
I'm happy to see the effort that is being put in the project. On the
other hand I have more general problems with the lumberjack/cee project
as a whole. Instead of listing issues like the above concretely here,
these are my general concerns:
1. Conclusions drawn from the discussions.
There were hundreds of mails sent to the mailing list about the pros and
cons of each solution/method (e.g. to use a flat namespace or not).
The spec in the wiki is evolving. According to William this will be
CEE 1.0 at some point.
Unless it is documented and summarized somewhere (e.g. FAQ section in the
wiki), people will keep repeating the same questions again what we
already discussed and imho not agreed on. I fail to see how the
discussions have influenced the design of the specification.
2. Stance of RedHat in this effort.
It's nice that some folks at RedHat took the lead and organized this
lumberjack project. This makes people think that they (RedHat) are fully
supporting the standardization effort. Yet the following makes it pretty
questionable:
AFAIK the authors of journal both work for RedHat. Instead of striving
for standardization, they are writing code to be later forced upon
millions of users (including us) which perfectly despises the effort of
those individuals (including me) who took their time to participate and
discuss here.
I thought by now RedHat would be a lot more organized company than this
to allow a bunch of hackers playing around. Even BSD can do better in
this regard.
Mainly these are the reasons why I have been silent in the past couple
weeks and decided not to reply because I felt that I'm just wasting my
time. I'll go waste it on something else instead.
Regards,
Botond
On Wed, 02 May 2012 10:21:53 +0200
Gergely Nagy <algernon(a)balabit.hu> wrote:
William Heinbockel <wheinbockel(a)gmail.com> writes:
> What I did was take the JSON field types and add datetime, ipv4, and ipv6 types.
> Then made a basic conversion from JSON --> XML and tried to align the
> libumberlog syntaxes with Keith's XML.
> I also added some notes about the "structured" vs. "inline"
field
> naming.
Sorry for the late reply, I've been swamped as of late. Nevertheless, my
former opinion that the inline representation is a very, very bad thing
still stands:
First of all, JSON is perfectly capable of representing structured data
(and the syntax format already describes that too!), bolting something
like the inline representation on it is both counter-intuitive for those
who worked with JSON, it's incompatible with anything that is not
explicitly aware of it: you can't just forward it to a database that
happens to accept JSON as-is, you'll have to translate the inline
representation into proper JSON structure. (For example, if I had a
producer that spew out CEE-JSON on one end, and an ElasticSearch indexer
on the other end, I'd need to convert inline-syntax, which would pretty
much destroy the whole idea of having a thin layer.)
It adds quite a bit of burden on the implementation side, and I still
can't see what benefit it would bring, apart from saving a few bytes on
the wire. I'm not entirely sure it would save bytes, either, by the
way.. For example:
{"foo!field1":1,"foo!field2":2,"foo!field3":3} vs
{"foo":{"field1":1,"field2":2,"field3":3}}
Proper structuring is shorteer pretty much the moment you have more than
two fields with the same 'object' prefix.
Furthermore, as mentioned above already, anything that speaks JSON,
understands the structures. None of them understand the inline
syntax. It's alien to JSON as much as trying to bolt on new types were.
It complicates both the sender side (do I want to send stuff as proper
JSON, or with inline representation?), it complicates things on the
consumer side too (do I need to expand inline syntax? if so, it will
likely turn into dotted-notation, and then how do I reassemble it back
if it needs to be forwarded?), and adds extra work on every level.
Granted, parsing nested structures is a bit more code, but seriously,
there are hundreds of libraries out there to work with JSON, multiple
libraries for pretty much every single language, and all of them can
handle nested structures just fine. There is hardly any extra work that
needs be done.
I don't buy the 'compatibility between syntaxes' thing, either. That's
what dot-notation is for, and it needs not be present on the wire.
Another thing that I don't like is that field names are much more
limited than JSON's limitations, and while allowing the full range JSON
allows is probably not a good idea, I'd at least add "-" to the allowed
set.
--
|8]
_______________________________________________
lumberjack-developers mailing list
lumberjack-developers(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/lumberjack-developers