[Interop-dev] OLSRd2 JSON APIs

[Nemesis]

Thanks for this useful information.

We should encourage more routing protocol devs to come here and share
news about what they are doing, especially JSON structures as we need
these structures in our libraries and web-apps to build useful features.

And I think it would be awsome if we could define another simple JSON
structure with the lowest common denominator of a network topology.
Probably as a third step after defining the monitoring JSON schema.
Am I asking for too much?

Federico


On 11/09/2014 07:32 PM, Henning Rogge wrote:
> Hi...
>
> at the moment I have a subsystem called "oonf_viewer" (olsr.org
> network framework) which I used to create three different plugins
> which can give JSON output.
>
> Each plugin has a number of subcommands, each of them giving an array
> of "key-value" lists, either in JSON or in text format. I always
> included the full "key" to understand each key-value array, so if you
> get information about your neighbor, you always have the local
> interface the viewer is talking about too.
>
> All of these plugins are primarily accessed via a telnet interface
> (tcp port for raw text commands), but I also have a plugin that makes
> the commands available as HTTP requests (just put telnet command and
> parameters as HTTP GET/POST parameters)
>
> The first two plugins are called "nhdpinfo" (Neighborhood Discovery
> Protocol) and "olsrv2info" (Optimized Link State Routing version 2).
> These give you similar information as the old "txtinfo/jsoninfo", but
> with more information.
>
> The third plugin is called "layer2info" and gives you metadata about
> the MAC layer... normally acquired (by a different plugin) over the
> nl80211 subsystem. At the moment I have a lot of data similar to the
> commands "iw station dump", "iw survey dump", "iw mpp dump" and "iw
> info".
>
> In addition to this it would be quite easy to allow OLSRd2 to read
> configuration files in JSON format. The configuration syntax is a
> plugin itself, as long as it supports "sections" (some of them with
> names), each of them with "key-value pairs" or "keys with lists of
> values" I could build a plugin to read the new format without changing
> the core.
>
> The last thing that might be interesting for you would be that the
> whole routing agent is built around a "small" core, with most of its
> capabilities (including the routing protocol function itself) as
> plugins. Both the core and the plugins can be either statically linked
> to a main program or be used as shared libraries.
>
> Henning Rogge