[occi-wg] Syntax of OCCI API

[Sam Johnston]

On Fri, Apr 17, 2009 at 10:48 AM, Chris Webb <chris.webb at elastichosts.com>wrote:

> Sam Johnston <samj at samj.net> writes:
>
> You've completely missed the point again. (Perhaps understandably, since
> you're not in the target audience for this format.)
>

Don't be so sure - I started life as a sysadmin (like many of us here I
guess) :)


> while read K V; do FOO; done
>

Granted that's trivial, but it rapidly gets more interesting when you have
multiple resources. As I said before though "*perhaps it's worth it just for
the (common) case of dealing with a single object*". I take it you're saying
that it is...

YAML's another interesting format, and as of 1.2 it's a perfect superset of
JSON <http://en.wikipedia.org/wiki/JSON#YAML> (that is, every JSON file is
also a YAML file), but it also fails the "one-liner parseability test"
miserably.


> is something you can type in a shell one-liner, which is the most
> interesting 'use case' (sorry, horrible jargon!) for shell people. This
> complex hack is not, and I note that you had to google for it rather than
> writing it off the top of your head, which should have been enough to make
> the point clear. (Incidentally, it doesn't get INI quoting right. Doing it
> correctly and allowing for backslash escapes is somewhat harder.)
>
> Whitespace separated KEY VALUE is better-defined than INI[1], can be parsed
> by
> shell read, by C strtok() or strsep(), and is generally pleasant to work
> with in languages without sophisticated string handling or data structures.
> Here's your sample translated to that format:
>
>  id decca5a5-8952-4004-9793-cdbbf05c3c63
>   category server
>  title Debian GNU/Linux 5.0 Virtual Appliance
>  summary Base installation of Debian GNU/Linux 5.0
>   content.cpu 2
>  content.memory 4Gb
>   link.disk[0].id 4696b561-a253-42b4-bd27-7aa4950e0a60
>  link.disk[0].dev sda
>  link.network[0].id 45a73b80-c957-4ae1-97c6-b70652eba1d1
>  link.network[0].dev eth0
>   mc.state RUNNING
>  br.meter.rate 0.10
>  br.meter.currency USD
>  br.meter.unit hours
>  br.meter.total 35.27
>  pm.monitor.cpu 75.2
>  pm.monitor.mem 1059374258
>   mc.ops.start
> http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/start
>  mc.ops.stop
> http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/stop
>  mc.ops.restart
> http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/restart
>  mc.ops.suspend
> http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/suspend
>
>   id 4696b561-a253-42b4-bd27-7aa4950e0a60
>   category storage
>  content.size 148251374
>   link.self virtual-disk.vmdk
>
>   id 45a73b80-c957-4ae1-97c6-b70652eba1d1
>   category network
>  content.vlan 4095
>  content.dhcp true
>  content.subnet 192.168.0.0
>  content.netmask 255.255.0.0
>  content.gateway 192.168.0.1
>   vnd.com.cisco.cdp true
>

Ok I've updated the wiki because I'm mostly sold on this. Things do get
rather more complicated when you have to parse multiple resources though,
which is my main sticking point now... I'm leaning towards the time/space
tradeoff of including the ID in each row somehow (in which case parsing into
a hash of hashes is trivial again).


> I'll not comment on the key space or conflation of objects into one
> namespace with a category key in this post.


Ok but don't forget to give us some feedback about this...


> [1] See.http://en.wikipedia.org/wiki/Initialization_file for details on
> some
>
of the variation seen in the wild. There's no formal spec to disambiguate.
>

Yeah I agree that INI files are not perfect, and for more advanced
formatting there's JSON/YAML so there's no point complicating text/plain to
the point where it's uninteresting for both audiences.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/3b95ea05/attachment.html