[Interop-dev] OLSRd2 JSON APIs

[Nemesis]

Hi Henning,

looking back the discussion we had, I was looking for some examples of
the JSON objects used in OLSRd2.

Could you please post an example?

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