Whats with the XML hate from the *nix people?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

AntiEverything

Senior member
Aug 5, 2004
939
0
0
The database I'm leaning towards is TextML by Ixiasoft. It's similar to a full text indexer such as dtSearch or Ultraseek, but it's built natively to handle XMLs uniqueness. Indexes can be setup very broadly so that it indexes the entire file in one index, or can be fine tuned such that you only index one element and can be setup as word, number, date or time indexes. The search engine has the standard boolean operators, plus proximity, range, etc. I can create as few or as many indexes as needed for best search results.

There are some databases that use XQuery to search, but they don't do quite what I want. This uses a proprietary (which is my only reservation about this software) XML based search language which will let me build fine tuned search alogrithms. Also, this server is focused on being an API for use in a custom application, and as such exposes all of its functionality without forcing me to use their interface.
 

AFB

Lifer
Jan 10, 2004
10,718
3
0
So the conclusion is:

XML sucks for:

Speed
Size

XML is good for:

Interoperability


?
 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
Originally posted by: amdfanboy
So the conclusion is:

XML sucks for:

Speed Not necessarily, most webservices need to be high performance. It really depends on your environment
Size
config files that unix admins need to understand :p
on a more serious note, anywhere where there are established practises that work fine without it
anywhere where the good items don't need to apply, specifially the 3rd point

XML is good for:

Interoperability
Quick development (that is interoperable)
expressing hierarchically arranged data (quite powerful)

?

Additions in italics
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: kamper
Originally posted by: amdfanboy
So the conclusion is:

XML sucks for:

Speed Not necessarily, most webservices need to be high performance. It really depends on your environment
Size
config files that unix admins need to understand :p
on a more serious note, anywhere where there are established practises that work fine without it
anywhere where the good items don't need to apply, specifially the 3rd point

XML is good for:

Interoperability
Quick development (that is interoperable)
expressing hierarchically arranged data (quite powerful)

?

Additions in italics

I can generally agree with that. ;)

One strength that was mentioned to me before would be to convert logs into XML format for display on the end user side, but keeping them available in plain text format would be a benefit too. ;)
 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
I think xml log files are never really a good idea (unless you're talking about really low traffic with highly complex data to output).

This is an instance where the speed (or lack thereof) is gonna hurt you. Log file writing absolutely has to be fast. The big reason though is that I don't think most logging really benefits from what xml offers. The actual data being output usually isn't very complex so xml doesn't help there. As for the extraneous data (message source, date/time, applicable error codes), I don't think it needs to be hierarchical either. Usually logging is linear based on many small additions over time. A well defined log syntax that isn't too difficult to parse functions just as well without all the fluff (and it's more human readable).
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: kamper
I think xml log files are never really a good idea (unless you're talking about really low traffic with highly complex data to output).

This is an instance where the speed (or lack thereof) is gonna hurt you. Log file writing absolutely has to be fast. The big reason though is that I don't think most logging really benefits from what xml offers. The actual data being output usually isn't very complex so xml doesn't help there. As for the extraneous data (message source, date/time, applicable error codes), I don't think it needs to be hierarchical either. Usually logging is linear based on many small additions over time. A well defined log syntax that isn't too difficult to parse functions just as well without all the fluff (and it's more human readable).

I don't want text logs to go away. Far from it. But end user applications that maybe import the logs and display them might use XML, especially if they're getting logs from several different sources.

I'm thinking data corrolation when it comes to security devices. Although, just a basic database is probably the best way, even if it is complicated...