[Interop-dev] [BMXd] make metric a optional property of NetworkRoutes, NetworkGraph, and each Route object

nemesis (spam-protected)
Sat Apr 9 12:33:14 CEST 2016


 On Tue, 5 Apr 2016 03:38:52 -0700, Mitar <(spam-protected)> wrote:
> Hi!
>
>>> one of the reason why I prefer the "multiple NetworkGraph/-Route"
>>> objects is that there is no guarantee that every topology has the 
>>> same
>>> links or even nodes.
>>
>> Mm.. I did not know this. I can imagine this being common for 
>> different
>> graphs representing ipv4 and ipv6, but even for different metrics?
>
> Is it definitely true in wlan slovenija network as we are migrating 
> from
> OLSR to Babel. So some nodes have only OLSR daemon, some both, some 
> just
> Babel.

 Now that you mentioned this, I also noticed NetworkGraph and 
 NetworkRoutes are currently
 not being used to represent an heterogeneous network topology, but they 
 are mostly
 being used to represent a topology of a specific routing protocol.

 But we should probably work more on the heterogeneous case too.

>>> Some of them might only participate in one topology, there doesn't
>>> even need to be a "full" topology.
>>
>> Surely in this type of case wrapping the items in a collection 
>> object is
>> the best approach.
>
> I think this is a question of should the producer of JSON be smart 
> and
> do something more complicated, or should the consumer be smart. I 
> think
> in this case producer should not be smart and make it so that it is
> simple to generate the file. We can always provide libraries to parse
> JSON files in some easier way, if it there are common tasks for
> consumers to do (like showing all links from a node no matter the
> routing protocol).

 The consumer could be smart, although I believe it's important to not 
 require that it HAS to be very smart,
 otherwise that would be a barrier that could slow down adoption.

 There will be developers which will have the experience and or 
 resources/time to write
 very smart consumers and there will be developers which will want to 
 start with simple implementations.
 If we allow anyone to start playing with the concepts we can evolve the 
 spec faster, and the spec will need
 to be iterated a few times at least.

 But the only way we can make up our mind is to write implementations.
 I already changed my mind on several initial concepts after having 
 written implementations, it has been an eye opener..

 Federico



More information about the Interop-dev mailing list