<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I just opened a new issue:<br>
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/issues/25">https://github.com/interop-dev/netjson/issues/25</a><br>
<br>
I copy the text here for the joy of the archive:<br>
<br>
-----------------------<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
It was mentioned in several discussions on the mailing list that
we need an object to represent neighbour link data.<br>
<br>
This was also referred to as "link-specific" or
"interface-specific".<br>
<br>
<b>the 1st proposed solution</b> is to add a new top-level member
in NetworkGraph would be sufficient, we have to find a good name
for this member and add it to the spec.<br>
<br>
<b>the other (2nd) possible solution</b> is changing the value of
the type attribute but keeping the exact same structure of
NetworkGraph. This could be an acceptable solution IMHO: we keep
the compatibility with NetworkGraph, we avoid adding too many
attributes but at the same time we also make a clear distinction
between the use case of the two objects.<br>
<br>
In my opinion, the first thing we should try to do is to have a
discussion about the terminology used by different routing
protocols to refer to this type of data.<br>
<br>
The second thing we have to do is to clearly state the goal / use
case for this object, what do we need to do with it? Why did we
add it?<br>
<br>
------------------------<br>
<br>
Federico<br>
<br>
<br>
On 09/03/2015 12:36 PM, Henning Rogge wrote:<br>
</div>
<blockquote
cite="mid:CAGnRvupn_fCc53vssVLj-hHQSCzBXcOE0yA-VvH3B_-L4z7O3Q@mail.gmail.com"
type="cite">
<pre wrap="">hi,
any comments on the idea of a "link specific" (or interface specific)
boolean flag for topologies?
This would allow olsrd(2) to export its Hello-based (interface
specific) data and its TC-based (node specific) data both with the
same NetJSON object while still keeping a chance for a processing
script to discover what to expect in the data.
Henning
On Thu, Sep 3, 2015 at 11:16 AM, Bastian Bittorf <a class="moz-txt-link-rfc2396E" href="mailto:bittorf@bluebottle.com"><bittorf@bluebottle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">* Nemesis <a class="moz-txt-link-rfc2396E" href="mailto:nemesis@ninux.org"><nemesis@ninux.org></a> [31.08.2015 09:06]:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/28/2015 02:04 PM, Bastian Bittorf wrote:
</pre>
<blockquote type="cite">
<pre wrap="">* Nemesis <a class="moz-txt-link-rfc2396E" href="mailto:nemesis@ninux.org"><nemesis@ninux.org></a> [28.08.2015 13:49]:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">this will not work, because one node can have different interfaces with
different types - how can i add that to properties?
</pre>
</blockquote>
<pre wrap="">Link objects can have properties too!
</pre>
</blockquote>
<pre wrap="">oh - soooo easy?! thank you:
<a class="moz-txt-link-freetext" href="http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html">http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html</a>
(mixed wireless+ethernet)
next week i will implement the subtypes. (frequency + channelwidth)
</pre>
</blockquote>
<pre wrap="">
Well I found out a few things to change in networkgraph to allow
customizing colors more easily.
For the moment try this crappy hack:
</pre>
</blockquote>
<pre wrap="">
ok, worked again on this issue (small net, dualradio-hardware 2.4/5 GHz mixed)
<a class="moz-txt-link-freetext" href="http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html">http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html</a>
<a class="moz-txt-link-freetext" href="http://intercity-vpn.de/networks/giancarlo/meshrdf/map.json">http://intercity-vpn.de/networks/giancarlo/meshrdf/map.json</a>
i introduced/hacked 3 new properties and modified your script:
link.carrier (e.g. ethernet|wireless)
link.frequency (e.g. 5180)
link.chanbw (e.g. 5)
now ethernet links have another color.
the next step would be:
change colors of the wireless links according to cost.
show speed of a link
show "nexthop" (but this is difficult, because the nexthop
can change when e.g. using source-specific-routing)
another thing: who feels responsible for this
javascript live-topology during battlemesh v6?
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=MXFz6QdfgP8">https://www.youtube.com/watch?v=MXFz6QdfgP8</a>
bye, bastian
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>