<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hey,<br>
<br>
On 11/02/2014 03:07 PM, Jernej Kos wrote:<br>
</div>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<pre wrap="">Hello!
Ok, thank you for your clarification.
</pre>
</blockquote>
<br>
Welcome<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite"><br>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>Latelly i've been working more on the network device configuration
<span class="moz-txt-citetags">> </span>object, which I simplified by calling it network-device-schema.
</pre>
</blockquote>
<pre wrap="">The proposed terminology does not help though. If you are proposing a
configuration schema then it should be named "Network Device
Configuration JSON Schema". And there should be another schema named
"Network Device Monitoring JSON Schema". Using a generic name and mixing
various things together is IMO not a good thing.
</pre>
</blockquote>
<br>
[CUT]<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<pre wrap="">Also, you propose the name "NetJSON". I personally don't like it because
it is, similar to "network-device-schema", much too generic. There
should be a different specification for configuration and a different
specification for monitoring.
</pre>
</blockquote>
<br>
Sorry, I was just abbreviating, I'm not very interested in the name
right now.<br>
<br>
I think that after we will have done a few iterations we'll have a
clearer idea.<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>It's true that the schema contains also dynamic attributes (like
<span class="moz-txt-citetags">> </span>noise and dbm) which change over time, and after you pointed that I
<span class="moz-txt-citetags">> </span>realized it might not have sense to put it there.
</pre>
</blockquote>
<pre wrap="">The difference is that the configuration schema is used to bring a
device into a specific state, while the monitoring schema can be used to
report on the current state of the device (which in ideal conditions
should somehow reflect what was configured and would also provide some
additional "dynamic" data).
But ok, let's focus on configuration. If I understand you correctly, we
are not aiming for an API but only for a self-contained JSON-based
serialization format of a node's configuration. This configuration
should IMO be:
i) Platform-independent (it should be able to describe any network
device configuration). This configuration can later be transformed
for example into OpenWrt UCI, but the schema itself should be
platform-independent.
</pre>
</blockquote>
<br>
Yea, I think it would be very useful if it could describe the common
attributes of any network device: a server, a router, a sensor, ecc.<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<pre wrap=""> ii) Extensible. As we have learned when redesigning the nodewatcher
platform, no one schema can provide everything so it should be
easily extensible when later one one needs to add some new
attributes.
</pre>
</blockquote>
<br>
Definitely.<br>
<br>
How do you think is best to achieve this?<br>
<br>
For example, GeoJSON has a "properties" key in which you can put
whatever attribute you need.<br>
<br>
Any other example?<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<pre wrap="">From my end, I can provide you with the platform-independent
configuration schema description that the current nodewatcher
development version is using:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://nodewatcher.readthedocs.org/en/development/node_config.html">https://nodewatcher.readthedocs.org/en/development/node_config.html</a>
An example simplified JSON serialization of this schema for an imaginary
node would be:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://gist.github.com/kostko/9b6eb44f373e17891d65">https://gist.github.com/kostko/9b6eb44f373e17891d65</a>
Note the absence of any platform-specific device identifiers (we are
using names like "lan0" and "wifi0" to denote interfaces -- these
identifiers are later resolved depending on the target device). Also
note that nodewatcher is actually able to validate whether this
configuration can be instantiated on a concrete target device.
</pre>
</blockquote>
<br>
Thank you.<br>
<br>
<blockquote cite="mid:54563ABB.80403@kos.mx" type="cite">
<pre wrap="">In case we come up with a good schema, I would be willing to provide an
implementation of nodewatcher v3 configuration exporter.</pre>
</blockquote>
<br>
I'm looking forward to go ahead.<br>
<br>
I'm very open to changes to the schema in order to get it right (or
as close as possible to right).<br>
<br>
I would like to get some more feedback from all the other
communities reading this list.<br>
<br>
Please let us know.<br>
<br>
As a next step I should probably compare the schema on the github
repo with the one at
<a class="moz-txt-link-freetext" href="https://gist.github.com/kostko/9b6eb44f373e17891d65">https://gist.github.com/kostko/9b6eb44f373e17891d65</a> and make a
"synthesis". <br>
Any other good JSON schema around?<br>
<strong style="color: rgb(34, 34, 34); font-family: sans-serif;
font-size: 12px; font-style: normal; font-variant: normal;
letter-spacing: normal; line-height: 14.77199935913086px; orphans:
auto; text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 215,
0);"></strong>
</body>
</html>