I was thinking more about the text format today (still believing there is significant value in multiple formats and slightly more work for a small handful of implementors VA an infinite number of clients) and was thinking RFC 822 ala HTTP headers could be interesting too... No need to be anti-XML... if you want to start from text and code the translations by hand then you're most welcome to do so. Sam On 5/7/09, Chris Webb <chris.webb@elastichosts.com> wrote:
Andre Merzky <andre@merzky.net> writes:
+1 for TXT, as that is most simple, flat, and easy to map to anything else. Well, you can screw up TXT, too, but we won't, right? ;-)
I'm standing back from the rest of the discussion as I've already advocated maximum format simplicity ad nauseam. However, I'll just quickly point out that the type of text format I have been proposing is a simple
KEY VALUE KEY VALUE
format, which can be read by a trivial shell fragment
while read K V; do [...]; done
Once it gets more complex than that, the sysadmin-friendliness starts to evaporate very quickly and you might as well use JSON. (For example, I remember another provider telling me that they'd offered CSV and nobody had used it. Frankly I'm not surprised given how much of a pain it is to parse correctly.)
In our own API, our 'native' format looks like this and it has worked very well. The code is simple and clean, feedback from users has been very positive, and people really do write five line shell scripts to drive our infrastructure in the way they might script their own machines. This was my original design aim. Meanwhile, we're able to do admin across the cluster with shell one-liners, which would require separate tools if our API were more clumsy.
We've structured our keys hierarchically using colons as a separator, so a text fragment
ide:0:0 08c92dd5-70a0-4f51-83d2-835919d254df nic:0:dhcp 91.203.56.132 nic:0:model e1000
might be viewed as equivalent to the flat JSON hash
{ "ide:0:0": "08c92dd5-70a0-4f51-83d2-835919d254df", "nic:0:dhcp": "91.203.56.132", "nic:0:model": "e1000" }
but equally as equivalent to the nested JSON hashes
{ "name": "TestServer", "cpu":4000, "mem":2048}
{ "ide": { 0: { 0: "08c92dd5-70a0-4f51-83d2-835919d254df" } }, "nic": { 0: { "dhcp": "91.203.56.132", "model": "e1000" } } }
The use of whitespace to separate keys from values and newlines to separate records restricts keys (but not values) to contain no spaces, and both keys and values to have no leading whitespace or embedded newlines. In our environment, this isn't a problem, but you would need to add shell-friendly \ escaping to the mix if you wanted to allow demented keys and values in a whitespace-separated text format.
Of course, if the standard goes with just JSON, it isn't a disaster from our point of view. We'll probably end up offering a small translation binary linking against libcurl to access it in the above flattened format. Seems a shame to force every casual user to compile and use a tool just to make the API usable from their command-line, though, when this isn't currently the case with our API.
It'll be hard to sell something like this to end-users as an improvement, but definitely less hard-to-sell a little JSON-parsing binary (which I could write standalone) than if the tool also needs you to compile and link against cumbersome XML and Atom libraries (which I wouldn't even think of trying to do standalone). I guess my vote is there strongly anti-xml/atom, vaguely positive about json, and strongly positive about simple plaintext.
Cheers,
Chris. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg