12012-04-30 21:20:432001:1418:1a9:eeab:218:f3ff:fe87:9494

Actually each community network do a lot of duplicated work to develop/maintain/manage their monitoring/managing systems

Join forces to develop a common code base for ours map servers. Very different community networks have, many differents needs, but very tiny core of common needs is still present.

Find What is really common, for example Can we assume on every community network: Each node have one or more device? Yes core for me Each device can belong just to one node? Yes core for me Each device have one or more neighbor ( that can belong to the same or to a different node ) attached by a link? Yes core for me Each link can be characterized by different values ( for example in Pisa we have TQ, but in Rome they have dBm and ETX )so here i think we can assume as common part that the link may exist or not and do "quality measurement" an extension <- Not core for me and so on so we can define a set of property i suggest in a json like sintax that all node and devices have so for example node.status={active, potencial} node.readeableName="Pisa::Eigenlab" node.slug="eigenlab" . . . device.father="" <- node sluf or id or something like that goes here device.reachMeAt="" <- something that permit to reach the device, can be for example one or more of eigenlab.n.ninux.org, 2001:1418:1a9:eeab:0:15:6dfd:71ce, 00:15:6d:fc:71:ce device.neigh="" <- things like 00:15:6d:7c:09:9e, pacinotti.n.ninux.org, 2001:1418:1a9:eeab:0:15:6d7d:99e and so on

Wow it is just the core but there are already a lot of information i have to put all of this manually :( ? No we have to do that more automatic possible, so we should put on netRing just device.reachMeAt more an userid+pass or an ssh authorized key or stuf like that so netRing can suck by himself all that stuff But how netRing know how to do that ?? Go to step 4 if you cannot wait ;)

Each community can define one or more extension property that some of their nodes/devices may have for example someone can be interested in what clients are connected to their node or how much traffic the node routed

We have to add supply a "template file" that explain to netRing ( obviously nerRing have to understand that language ) how to do that and it could be somethings like that 1 if the device accept clients. 0 if the device is a pure node ( doesn't accept ethernet and wireless clients ) 1 if the device is accepting wireless clients 0 otherwise Broadcasted SSID on wireless mesh interfaces Wireless mesh channel ]]>