[Interop-dev] Network Device JSON Schema

[Ralf Schlatterbeck]

Jernej, Federico, concerning the representation of objects:
I'd like to first define what attributes we need and later how to call
an object. If such a thing consists of several objects (as in Jernej's
implementation) is probably secondary.

Note that Christian Tanzer and me have started to write up what we know
about other Node database implementations, the attributes used and the
names for them. This could be a start to define a common API.

This is on github at https://github.com/Common-Node-DB/paper
We've tried to summarize the schemas from what we found on the net and
what we found out by asking people.  This is in background.txt

Note that we were unable (too dumb :-) to understand the nodewatcher
schema even after asking. Jernej: Maybe you want to take a look at what
there already is (see background.txt in the repo above) and contribute a
section on nodewatcher? This would also be an opportunity to better
explain your (unique) approach to modularisation -- as this discussion
shows -- and my experience with trying to understand the nodewatcher
schema -- this is not immediately obvious. At least not to me.

Note that I could give you github access to the Common-Node-DB/paper/
repo -- or you fork and send merge requests. My proposal would be to
document what there is to later define what a common api should look
like. The idea is to write a paper -- preferrably with all of you as
authors -- that defines a minimum common api.

That said: We *have* started to write a proposal on a common api in
common-api.txt but this is of course still subject to change.

I think the two common artefacts that a common api must support are what
we call a "Node" and a "Device":

- A Node is at some (geo-) location and several devices may be installed
  at a Node. Typically a Node has an owner and maybe some additional
  people managing it.
- A device is something that communicates via the network. It typically
  has network interfaces which in turn are associated with IP addresses.
  It can also have wireless parameters if it contains a radio.

We also want to discuss which attributes are configuration parameters
and which are dynamic (measured) data. From the schema at
https://github.com/interop-dev/network-device-schema/issues/1
I understand that much of what nodewatcher-agent displays is dynamic
data. In the current API proposal (above) we're mostly dealing with
configuration data. Note that we're trying to integrate both, dynamic
and static data, into a user interface that we call the "dashboard".

We have an implementation of our API (the 'internal' api, not the
proposed common api) up at https://ff-nodedb.funkfeuer.at -- I'm working
on this for a presentation on Wed/Thu this week so it may not be fully
functional during the next days. In particular the self-documenting
object model (where you can click on each of the classes and get a
description of the attributes) is currently not working. You can find an
overview graphics of the object model on the starting page of the github
project at https://github.com/CNDB/CNDB/
You can explore the api at https://ff-nodedb.funkfeuer.at/api
Note that this database is anonymized, so you'll find only "funkfeuer"
persons in there.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: (spam-protected)
allmenda.com member                     email: (spam-protected)