libidf I.


Wouldn’t it be nice too be see things like this just work?

  <entry key="" value="72" />
  <entry key="hw.acpi.battery.time" value="315" />

or …

  "lo0": {
    "metric": 0,
    "mtu": 16384,
    "inet": [127, 0, 0, 1],

Simpy put, machine-readable output of (non-)standard utilities. Just imagine every command line utility on your UNIX that displays some useful output that might be useful for some programmer out there in the nice form easily crunchable by the program. Possible examples are:

  • ifconfig
  • ctfdump
  • sysctl
  • find & ls
  • netstat, procstat
  • ping, traceroute
  • insert your tool here

If this sounds just one bit interesting and important, continue reading.


You see, I am not the only one to think of this, take this repository as an example. Don’t get me wrong, it is a nice piece of software. The problem with such approach is the scalability – if I make the JSON exporter for every one of the utilities mentioned above, I might as well quit my university and start working on that. Now let’s imagine there is another company that loves XML or maybe C data type notation to exchange data. For every format we add, the code of these utilities gets bulkier and the original purpose of the program will be hidden in hundreds lines of code emitting your favourite format. If we denote the number of formats F, we might say we have a 1:approach.

The same goes with adding new utility to your arsenal of machine-readable-output-creating programs. You will need to teach it to speak every format you fancy. Writing tenth YAML converter must be fun, not. If we denote number of utilities U, we might say we have a U:1 approach.

So, what do we want exactly? U:F.

P.S.: Do not get me started on the situation, when your favourite XML library is no longer supported or changed the license to an incompatible one and you have to rewrite every one of your tools.


We want to write a YAML/JSON/XML/… converter only once. And, maybe even more importantly, we want to infect the source of the utility with only one data-ventiling code. Where does that leave us? We need an intermediate data format. Intermediate Data Format Library to be precise, let’s call it libidf.

More about the design and implementation of this library in next posts. Stay tuned!

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s