Whats with the XML hate from the *nix people?
- Thread starter AFB
- Start date
XML is overused and has become wayyy to complex. It's good for having ubiquitous data, but when I have to create an XSD to define my XML config file, blahhh.
Well I don't think it's so much as "hate", it's more of a "disgust".
Note, that personally I don't realy care. I figure it's up to the author to choose what he/she/they wants to use and that's because they are the ones that are developing the actual application so if anybody knows, they should.
That being said, your going to get a kneejerk negative reaction because XML is simply a data encapuslation format, but people think it's something special. It's the market hype, it causes a alergic reaction...
For instance take plain text configuration files vs XML formatted text configuration files. To unix guys, it's a solved problem and plain text solves it and it has lots of benifits in itself. Same thing with log files. It's a "been there done that" attitude. Unix itself is highly developed and evolved entity, there have been hundreds of different ways of doing any one thing and what survives lasted this long, not because of hype or irrational stuborness, but because it works.
You want clean, simple systems. Marketting/fanboy-sh bullet points are the anti-christ of Unix.
For instance other terms that cause kneejerk negative reactions:
Object Oriented programming
Java
C++
Extreme Programming
You get things like: "You should re-write the kernel in C++ so that you can reap the benifits of Object Oriented programming, here are all the reason why: blahblahblahblahblab"
Reply: "OO is usefull in some situations is, but we don't care about those benifits it works fine without it. Rewriting what works is pointless and it's just going to break lots of stuff"
Counter point: "But C is crap! I mean get with the program, so-and-so and so-and-so uses C++ and is faster/stable/easier to manage."
Now what is going on a average Unix developer mind: "Grrrrr....."
Same thing with java:
"Use Java, it's portable!"
OSUG(Old School Unix Guy.): "C is portable"
"But you have to deal with memory issues!"
OSUG: "That's why we have Perl/Python so we dont' have to deal with that crap if it's not needed"
"But Java is faster!!"
OSUG: "If you care about speed, use C or whatever"
"Use Java it's portable and you can use Extreme Programming techics with OO style code management to leverage your cross platform code to produce multi-tiered synergy in your overal market strategery and then run it all on super-slick XML formats that will speed your developement time and reduce costs!! And if Java is to slow use C++, C will make your programs a unmanageble mess (then runs on for 15 minutes giving examples of bad C programming) and Microsoft is going to kick your but with C# if you don't modernize!!!"
OSUG: "Grrr...."
So if you want to have a constructive conversation, then you point out things you think would benifit from XML, and you'll get to the point were you'll get shot down a few times, but find some places were XML would be great, eventually.
Note, that personally I don't realy care. I figure it's up to the author to choose what he/she/they wants to use and that's because they are the ones that are developing the actual application so if anybody knows, they should.
That being said, your going to get a kneejerk negative reaction because XML is simply a data encapuslation format, but people think it's something special. It's the market hype, it causes a alergic reaction...
For instance take plain text configuration files vs XML formatted text configuration files. To unix guys, it's a solved problem and plain text solves it and it has lots of benifits in itself. Same thing with log files. It's a "been there done that" attitude. Unix itself is highly developed and evolved entity, there have been hundreds of different ways of doing any one thing and what survives lasted this long, not because of hype or irrational stuborness, but because it works.
You want clean, simple systems. Marketting/fanboy-sh bullet points are the anti-christ of Unix.
For instance other terms that cause kneejerk negative reactions:
Object Oriented programming
Java
C++
Extreme Programming
You get things like: "You should re-write the kernel in C++ so that you can reap the benifits of Object Oriented programming, here are all the reason why: blahblahblahblahblab"
Reply: "OO is usefull in some situations is, but we don't care about those benifits it works fine without it. Rewriting what works is pointless and it's just going to break lots of stuff"
Counter point: "But C is crap! I mean get with the program, so-and-so and so-and-so uses C++ and is faster/stable/easier to manage."
Now what is going on a average Unix developer mind: "Grrrrr....."
Same thing with java:
"Use Java, it's portable!"
OSUG(Old School Unix Guy.): "C is portable"
"But you have to deal with memory issues!"
OSUG: "That's why we have Perl/Python so we dont' have to deal with that crap if it's not needed"
"But Java is faster!!"
OSUG: "If you care about speed, use C or whatever"
"Use Java it's portable and you can use Extreme Programming techics with OO style code management to leverage your cross platform code to produce multi-tiered synergy in your overal market strategery and then run it all on super-slick XML formats that will speed your developement time and reduce costs!! And if Java is to slow use C++, C will make your programs a unmanageble mess (then runs on for 15 minutes giving examples of bad C programming) and Microsoft is going to kick your but with C# if you don't modernize!!!"
OSUG: "Grrr...."
So if you want to have a constructive conversation, then you point out things you think would benifit from XML, and you'll get to the point were you'll get shot down a few times, but find some places were XML would be great, eventually.
XML itself is not great. The virtually universal acceptnace of XML is. The biggest problem with using XML always is the size of the data. Sometimes it's just impractical to have enormous XML files.
I've never understood proprietary text files as a preferred anything over XML. Maybe CSV files, but those aren't proprietary. With XML almost every platform has a pretty strong set of functions to search, manipulate, validate, import, and export to XML.
I don't know enough about the low-level unix stuff, but I know that if some programmer here used a proprietary text format over XML just because of their "preference", I would consider this person a pretty weak programmer.
I've never understood proprietary text files as a preferred anything over XML. Maybe CSV files, but those aren't proprietary. With XML almost every platform has a pretty strong set of functions to search, manipulate, validate, import, and export to XML.
I don't know enough about the low-level unix stuff, but I know that if some programmer here used a proprietary text format over XML just because of their "preference", I would consider this person a pretty weak programmer.
It's not so much preference. Generally you keep configuration files in plain text and a administrator uses a configuration editing tool (vi/emacs/pico/nano or other favorite text editing program) to directly interact with them.
Go and download and learn Debian Linux or FreeBSD Unix learn how they work and then you'd understand the attitude about things like this. (not that you nessicarially like it. just understand it.)
General system-wide configuration tools, such as wizards or configuration panels, are a nice convienence, but it's much better to allow convient direct access to the configuration files by the end user.
Now GUI preferences aren't so important. For instance if my Gnome desktop gets kinda screwed up and I can't fix it, then in worse case scenero I just wipe out my user preferences with a "rm -rf ~/.gconf* ~/.gnome*" and they will be regernerated automaticly back to defaults next time I start up my desktop. (of course I loose all my settings) Those are kept in XML format, BTW. (can't do that to system-wide format stuff, it's deleted forever. But text files are easy to backup into a tarball (and of course XML is text files, too
))edit:
I forgot to mention this:
In Unix-land when it comes to text files
equals Perl. It's a mainstay tool of every experianced Unix administrator.
And sed, and grep, and |, and awk....
I think the attatched code is more difficult to understand (from the perspective of someone with absolutely no XML knowledge) than a well documented plain text file.
People see XML as magic, or as a checklist item. Like in drag's examples "you should change your efficient binary data format to XML because it will then be XML-tastic!" And it will be 5 - 10 times the size, and tremendously slower to process. But it will be XML-tastic!
Using XML offers validation tools and access to processing libraries, but you still have to write a lot of your own code to load or save data, just as with a text or binary format. When exchanging data with another program, that other program still needs code written to deal with the specific contents of the XML, down to the exact tag names. In some cases both programs might be using some domain-specific library / definition but you still need to write code to match tags to your own variables.
I don't hate XML, I just don't worship it. But then I'm a Windows developer
Using XML offers validation tools and access to processing libraries, but you still have to write a lot of your own code to load or save data, just as with a text or binary format. When exchanging data with another program, that other program still needs code written to deal with the specific contents of the XML, down to the exact tag names. In some cases both programs might be using some domain-specific library / definition but you still need to write code to match tags to your own variables.
I don't hate XML, I just don't worship it. But then I'm a Windows developer
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
lol at all of that :laugh: Granted, anyone that thinks that a kernel should be rewritten in a "cooler" language should be kicked really hard. But, on the other hand, anyone who thinks that xml isn't extremely useful for high level, web based applications and that custom binary formats should be used instead will probably end up coming out with an application 5 years behind the times, never get any peers to integrate with it and will have no technical advantage because networking/computing speeds will have sped up enough by then anyways. Alright, I'm being a little extreme...
Not so much. Heard of datamapping? I have worked on a system where an xml message comes in and is automatically converted to a set of data objects (including nested objects, collections, you name it). The only programmer effort required is to define the data object (in java, in this case) and a specification of which xml fields map to which dataobject fields (which would have to be done anyways). The mapping file is written in, couldn't you guess?
: xml.I think that the people that bash xml because it's overhyped are just as misinformed as the people who praise it because it's overhyped.
I do a fair amount of work with SOAP, which seems similar to your datamapping. My point wasn't that you had to manually write your own tags to the file, but that both client and server (or peer and peer) do need code to decide what to marshal, and one the other end to unmarshal and process data. Also, if the other program is not using the same datamapping library/framework it might have to write the complete "state machine" mapping from scratch as usual instead of having it generated by your XML definition.
People get the idea (including article writers) that as soon as you have a WSDL definition of your SOAP services, a program can automagically bring in or send out data with no extra coding, when actually both sides do still need code to make the SOAP calls and to decide what variables to bind the data to. Sometimes by the time you're finished it's much more work than the old plain HTTP / HTML we used to use for web services.
People get the idea (including article writers) that as soon as you have a WSDL definition of your SOAP services, a program can automagically bring in or send out data with no extra coding, when actually both sides do still need code to make the SOAP calls and to decide what variables to bind the data to. Sometimes by the time you're finished it's much more work than the old plain HTTP / HTML we used to use for web services.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Most of my work is Windows client-side in C++, but that looks like a good tool for java, especially (for peers or client/server) if both programs are java. If the other program is C/C++ you're back to building up object mappngs tag by tag.Originally posted by: kamper
I guess I'm not teaching you anything
XML plus a shared toolkit can really simplify data sharing, but the hype about XML being open and interoperable with other toolkits is a bit overstated. People hype XML as instant binding between any two programs or XML toolkits, but think about the work you'd go through unmarshallng your objects if for some reason you couldn't use the Castor framework in one of your prgrams.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
My point is that it doesn't matter if both sides are implemented in java. We used castor on our side to (un)marshall the objects and we shared the message specifications with the company that was writing the other end of the application. They were using .NET and we didn't care how they chose to handle that xml, I assume they had a framework that they wrote similar mappings for which would then generate .NET data objects for their use. The only thing that mattered is that both sides agreed on an allowed document structure (fairly simple to do) but how we parse/handle it is completely irrelevant.
True, and using XML probably saved some time over creating a proprietary format.
XML is definitely a useful tool, it's just that it's been hyped as being much more than that, and us old-timers roll our eyes at articles claiming it will somehow do all of our work for us
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Maybe it's a case of experience. You "old-timers" already know how to do all your work for yourselves and so a new tool may very well add unnecessary complexity (kinda like using c++ for a kernel). Us younguns don't have as much experience creating things from scratch (and it would seem that we might not ever need it) so xml is quick especially when you have things like http (in the form of tomcat), axis and castor to do the nitty-gritty for you. With so much xml around it becomes almost a mindset, a design philosophy.
It looks like you're pretty much in the middle, having a view of both worlds. I bet you're the best off of all of us
It looks like you're pretty much in the middle, having a view of both worlds. I bet you're the best off of all of us
Write up an XML version of the httpd.conf. Make sure apache will not need more than minor changes to use it. Make sure it is a comparable size to the existing httpd.conf. And most importantly, make sure it is easy enough for any seasoned admin to convert to within minutes and understand fully.
We can talk about conving the world to switch later.
We can talk about conving the world to switch later.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Sure, except I'm not familiar with all the data that needs to be specified. A hierarchical format might not be necessary for the current requirements. In order to properly use xml you might end up changing the semantics of the configuration. But, note that part of the file already uses an xml like structure (<Directory> and the like).
That depends entirely on how abstractly the config information location is written at the moment.
Not going to happen
But why should it?That's extremely simple (at least the conversion part). You can parse the current conf file programmatically. You can generate the xml config file programatically. You can write a script/program to convert all information and comments perfectly. Whether or not the crusty old admin takes the time to learn to understand xml is entirely up to him
I hope I never implied that apache should no longer use its current conf file format. All I would like to say is that I think xml is appropriate, the current system works well too. Perhaps a happy medium would be the ability of the server to handle either format.We can talk about conving the world to switch later.
Originally posted by: kamper
Sure, except I'm not familiar with all the data that needs to be specified. A hierarchical format might not be necessary for the current requirements. In order to properly use xml you might end up changing the semantics of the configuration. But, note that part of the file already uses an xml like structure (<Directory> and the like).
That depends entirely on how abstractly the config information location is written at the moment.
Not going to happen
9600bps is slow.
That's extremely simple (at least the conversion part). You can parse the current conf file programmatically. You can generate the xml config file programatically. You can write a script/program to convert all information and comments perfectly. Whether or not the crusty old admin takes the time to learn to understand xml is entirely up to him
I hope I never implied that apache should no longer use its current conf file format. All I would like to say is that I think xml is appropriate, the current system works well too. Perhaps a happy medium would be the ability of the server to handle either format.We can talk about conving the world to switch later.
Apache would need a new parser, that does not interfere with the old one. Would it need libxml? It would need teams to test both configurations, as well as teams to maintain them.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Point taken, but how often do you transmit httpd.conf over the internet?9600bps is slow.
Again, point taken. Unneeded bloat is never good (although I contest that the xml version would be easier to maintain
). I'd be willing to bet that xml has already touched apache in such a way that the xml parsing library needed would already be available at no extra cost. If not, I'm clearly in the wrong.XMLs biggest draw for me personally is it's heirarchical nature. The company I work for has been accessing tens of millions of real estate listings out of an RDBMS for years. The processes required to normalize the data, insert it into a database, and the joins required to search and reassemble the data are murder on my servers, and too time consuming from a development standpoint. Dealing with hundreds of tables and hundreds of link tables is no fun.
I'm migrating to XML as a data format and going to use an XML database as a repository and for full text indexing, searching and retrieval. Right now I expect to cut my hardware needs by 50% or better. More importantly, I'm hoping that the time required for the code monkeys to write conversions which take the data from it's original format into our XML should be about half what it is now. That's a lot less overtime, and faster response times when our data sources change their export format without telling us.
At least that's how I'm selling it to my boss, so I'd better hope I'm right in my estimates.
The usefullness of XML simply depends on the nature of the data. Not everything requires or can even make use of the format. Buzzwords aside, it does have real world advantages.
I'm migrating to XML as a data format and going to use an XML database as a repository and for full text indexing, searching and retrieval. Right now I expect to cut my hardware needs by 50% or better. More importantly, I'm hoping that the time required for the code monkeys to write conversions which take the data from it's original format into our XML should be about half what it is now. That's a lot less overtime, and faster response times when our data sources change their export format without telling us.
At least that's how I'm selling it to my boss, so I'd better hope I'm right in my estimates.
The usefullness of XML simply depends on the nature of the data. Not everything requires or can even make use of the format. Buzzwords aside, it does have real world advantages.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Now that's an interesting take on the issue
Could you elaborate on the xml database AntiEverything? Is this a new fangled product out there or does it piggyback on current relational databases or are you developing this in house?
Seems kind of counter-intuitive to speed things up by replacing a conventional database with xml I hope it works out and that your boss buys it if it truly is better.
Could you elaborate on the xml database AntiEverything? Is this a new fangled product out there or does it piggyback on current relational databases or are you developing this in house?
Seems kind of counter-intuitive to speed things up by replacing a conventional database with xml
I hope it works out and that your boss buys it if it truly is better.Originally posted by: kamper
Point taken, but how often do you transmit httpd.conf over the internet?9600bps is slow.
Again, point taken. Unneeded bloat is never good (although I contest that the xml version would be easier to maintain
I'm sure the XML version would be easier to maintain. Apache is probably a bad example though, because of the fact it is similar to XML.
I think a transition to XML everywhere would be too costly to be worth the negligable benefits. Writing documentation isn't tough, and it's something people can understand without learning XML.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter