Re: Re[2]: [logs] Logging: World Domination

avalonat_private

In some mail from Bennett Todd, sie said:
[...]
> XML, which is
> just SGML with some of the more obscure cruft trimmed off, is useful
> in the same places that SGML is useful. It remains a lousy choice
> for lightweight applications. Its flexibility is actually in
> opposition to the goal of the project currently under discussion.

Au contraire.  XML can be extremely flexible.
It all comes down to the design of the DTD.

[...]
> Or we could express the same thing with XML, to buy ourselves some
> buzzword compliance at the expense of a preposterously more complex
> (=3D=3Dinefficient, nonportable, bugridden, security-problem-inducing)
> parser for a class of complex structured languages. If we want to
> sabotage this project, XML would be a fine step.

I find these arguments non-ingenous and smack more of someone that
is unwilling to become familiar with a new technical thing.

All of the problems you list in the ()'s are programmer related,
not specifically XML related.

I'll counter your "sabotage" statement by saying if there's one
thing that could possibly make any project here be seen as irrelevant
by the outside world then that would be to use something else in
place of XML (or to not use it).  You might not like that idea, and
may start off without it, but I guarantee you that if someone else
does decide to start a similar project and it does use XML then
this one will be forgotten about.

[...]
> That's the whole point to a canonical reference format. XML is more
> complex than we need for this application; the only things it
> contributes --- increased flexibility in record format, increased
> likelihood of security and performance and portability problems due
> to the vastly more complex parser required --- are things that we do
> not want.

Is high performance a security goal ?  If so, then why are we bothering
with a text based token format at all ?  Likewise if security is a real
goal, using text is never going to be the first choice because dealing
with "arbitrary" text strings is a PITA.  Not only that, it increases
the scope for making coding errors that lead fo security problems.

The only complex part of XML is in the parsing.  I spent a few minutes
yesterday modifying syslog(3) for NetBSD to generate XML format messages.
It maybe be half a dozen more lines of code but it is not hugely
computationly expensive code either.  The problem of XML data being
CPU intensive to parse is a problem for the application programmer
to handle in how they manage receiving large amounts of data.
FWIW, it would be about the same number of extra LOC to use any format.

[...]
> > There are now a number of high-performance validating XML parsers=20
> > available, both commercial and open source.
> 
> Find me one anywhere approaching the simplicity of
> split-on-whitespace and I get interested. If it buys us nothing but
> increased complexity, then it's a lose.

"split on whitespace" is an oversimplification, unless you've already
decided how to reformat parameters that naturally have whitespaces in
them (without using quotes.)

[...]
> If we want to be able to process the XML in a fashion more automated
> than existing syslog noise, we have to force the XML to be
> structured and conform to strict rules. We can enforce the same
> constraints on a string of tokens. XML doesn't make this job easier.

No, using XML gives you the ability to easily integrate that data from
logging into other applications that can deal with XML.  That might be
a "plugin" for Oracle or whatever else.  If you come up with your own
text format then you need to also work on the means to pass that data
to other applications in a manner that they can make sense of.

[...]
> We must enforce the same data structuring requirements either way; if
> we _use_ the extra flexibility XML gives us, we lose the ability to
> automate the processing. They're equivalent for this job; let's use
> the simpler one.

I don't see how XML is mutually exclusive with automated processing.

[...]
> XML is more work for everybody to implement, and makes the job
> harder, and less likely to succeed. XML sucks.

No, it isn't more work for everybody to implement.

Anything new is going to be more work for anyone to implement.

Whether you happen to choose free flowing text or XML, it makes
no difference, from the sending side.

On the parsing side, yes, you need to do more to handle XML properly.
I don't see that as a bad thing, more that for people to get their
messages to be received and handled they need to generate properly
formatted ones, not just any junk they feel like throwing in/out.

Darren
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
https://lists.shmoo.com/mailman/listinfo/loganalysis