Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libvirt – The Unsung Hero of Cloud Computing (2013)

vyomtech.com

Post reply on HN
Print view View original

51–60 of 113 posts

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#51

Post by andyjohnson0 »

Polylactic_acid wrote: post #20
shmerl wrote: post #10

Earlier quoted context omitted.

What's wrong with XML?

Im sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have 4 5 or you could have . There is often no consistency within a single spec over how this should be done let alone between different specs. JSON feels much more logical to me as well as being a whole lot simpler. If only it supported comments.

The functionality isn't quite duplicated. Attributes are order-independent and can't have child attributes, for example.

As far as I know, the original intention of the language designers was that attributes are for metadata and sub-elements are for data. For non-trivial schemas that form part of a data contract between systems or organisations, and/or are expected to evolve over time, I tend to stick to this approach. It results in more verbose data, but in my experience thats almost never a problem and can be an advantage if I have to drop into the data and actually read it.

For smaller-scale and internal schemas (e.g. internal tool configs) the terseness of e.g. definitely wins out over design purity for me. JSON would be equally good for this.

I work on enterprise integration and messaging stuff and I deal with a lot of XML data every day. JSON has its uses (particularly when you control both ends of the serialisation pipeline) but for me XML has a lot of advantages.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#52

Post by agumonkey »

hinkley wrote: post #14
stochastastic wrote: post #9

Earlier quoted context omitted.

Ha! ... that’s a laugh of bitter jealousy. I’ve dealt with XML, but I’ve never with XML that came with a schema, or which would have reliably followed one. Not saying schema-less formats are great, but at least I can eyeball them to see what is going on.

XML turned everyone into a language designer during an era where we already knew that language design was a rare skill. If I saw a schema, which I often didn’t, it usually didn’t say what the author thought it said. To a first order approximation, all the good ones I saw came from one tool (XMLSpy possibly?) Namespaces ended up in a sort of uncanny valley that I can’t quite do justice to.

I'd even classical OO did the same.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#53

Post by eska »

z3t4 wrote: post #18
foepys wrote: post #8

Earlier quoted context omitted.

JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…

I load config files as JS (not JSON). And only use JSON for data serialization. In plain JS you can have comments and dont have to put quotes around properties. Not saying everyone should have a full JS parser for their config files, but its really nice.

So you're running eval on your config data? Not feasible for external data.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#54

Post by agumonkey »

shmerl wrote: post #21
Polylactic_acid wrote: post #20

Earlier quoted context omitted.

Im sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have 4 5 or you could have . There is often no consistency within a single spec over how this should be done let alone between different specs. JSON feels much more logical to me as well as being a whole lot simpler. If only it supported comments.

Yeah, I agree. Though I usually view elements as data and attributes as metadata, but in practice the usage is all over the place.

Or it results in neverending discussions about when to do what and why it's somehow better

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#55

Post by wokkel »

laurencerowe wrote: post #24
shmerl wrote: post #10

Earlier quoted context omitted.

What's wrong with XML?

For those working in dynamic languages (JavaScript, Python, Perl, Ruby, etc.) JSON maps directly onto built-in language data types and structures making it trivial to work with. With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures. This is less of a concern for statically typed languages where you usually have to mar…

It's trivial until you run into a date-field. I've connected some JSON based exchanges to each other and just created an XML intermediary format to have a single canonical model and do the various translations to/from the other systems from there.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#56

Post by formerly_proven »

dijit wrote: post #42
formerly_proven wrote: post #32

Earlier quoted context omitted.

> JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Do this with libvirt please and report back how it went :)

I actually _do_ do this quite often. Often w.r.t local changes (attaching network devices or storage devices). If you fire up `virsh edit ` you get a live view of the resource which can be updated in place. This is great to comment out some things and uncomment things for quick and dirty modifications. (some require a VM restart though).

That has to be a recent change, because editing the XML used to cause it to roundtrip through libvirt, which doesn't keep the XML DOM around; anything not in the internal C structs would be removed from the files, including all comments.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#57

Post by necovek »

formerly_proven wrote: post #32
foepys wrote: post #8

Earlier quoted context omitted.

JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…

> JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Do this with libvirt please and report back how it went :)

Libvirt uses proper XML parser so that's almost certainly a non-issue. The problem with libvirt XML files is that they are snapshots, and that they lack obvious defaults.

What I mean with "snapshots" is that you can't edit an XML file for a running VM on disk, but instead have to go through either virt-manager or virsh dump/load function. If you do edit an existing XML file on disk, it will just overwrite it for you.

And XML format is a bit more verbose simply because XML schema writers make it so. SGML could be even nicer for human writers.

As for comments in JSON, many parsers are not strict and would let you insert arbitrary elements, so you might add {"comment":"whatevah"} where you need it.

An example of terse XML would be:

or

  postgred

  8gb

  1tb

compared to JSON:

{

  "name": "postgres",

  "ram": "8gb",

  "disk":"1tb"
}

They are not equally descriptive, but that's because you do not need a top-level element in JSON (you could have it).

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#58

Post by wokkel »

nine_k wrote: post #43
brmgb wrote: post #36

Earlier quoted context omitted.

If only you could specify in your schema that element must be unique. But wait a minute ! Actually, you can. That's what the unique attribute does. And here lies the main problem of XML. As a technology, it is better than its reputation. Sadly, next to no one knows how to use it properly.

XML did a number of things right. Too bad it was initially envisioned as a text markup language, with tags sparsely strewn around the text, and not as a data representation format. So, the syntax ended up both overly cumbersome (see closing tags) and festooned with logically unnecessary shorthands like node attributes. Then, the terror of entities. XSLT is a brilliant language, I'd say the first pure functional langu…

I see no issue except from the entities. Which by and large have died anyway as those come from DTDs and not from XSDs. I do not see why closing tags are a problem: my editor will insert them and it makes parsing the XML much easier/less error prone. XSLT is brilliant indeed (and to my eye quite readable, but then again I also like regexp ;-)

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#59

Post by riffraff »

stochastastic wrote: post #9
catmanjan wrote: post #4

Earlier quoted context omitted.

Yep, if people think XML has aged poorly, wait until these schema-less formats age...

Ha! ... that’s a laugh of bitter jealousy. I’ve dealt with XML, but I’ve never with XML that came with a schema, or which would have reliably followed one. Not saying schema-less formats are great, but at least I can eyeball them to see what is going on.

> but I’ve never with XML that came with a schema

how about docbook? It's been a while, but I think even eclipse's project.xml used to have a schema, and would validate it if you tried modifying it yourself.

Re: Libvirt – The Unsung Hero of Cloud Computing (2013)

#60

Post by riffraff »

laurencerowe wrote: post #24
shmerl wrote: post #10

Earlier quoted context omitted.

What's wrong with XML?

For those working in dynamic languages (JavaScript, Python, Perl, Ruby, etc.) JSON maps directly onto built-in language data types and structures making it trivial to work with. With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures. This is less of a concern for statically typed languages where you usually have to mar…

XMLRPC[0] defined a trivial mapping of the same data structures (structs, arrays, scalars) in the '90s.

The real advantage of JSON was (IMHO) that it didn't let you do _anything else_.

[0] http://xmlrpc.com/spec.md

Post reply on HN