[Interop-dev] CNML/Database Brainstorming: Help!

[Gioacchino Mazzurco]

On 05/11/12 18:16, Federico Capoano wrote:
> *Zones*
> are zone intended for routing only or are they also geographic zones?
> Do we need to have 2 separate tables one for routing zones and one for
> geographic zones or can they be joined together?
> Do zones have routing protocol info in it? I'd suggest a
> "default_protocol" field.
> in CNML now zones are rectangular. Is there anybody that would like to
> have them polygonal?
> 
> Shall we define a Zone?
> Me and Ralf propose the following:
> /A zone is an indpendent part of a network which is run by a group of
> people in a geographic location.
> //Zones can be nested (how many levels of nest?).
> It should be possible to extract information from one or several zones.
> Every zone is free to run its own nodeDB server.
> Different nodeDB servers shall be interoperable with other zones.
> Interoperability is achieved with a RESTful API/.
> 
I think that geographical and routing zones must be two separated entity
because they are completely different concepts and it will be a big mess
to join them together

> *Devices & Servers*
> in the existing nodeDB i haven't seen yet (i haven't studied them all in
> detail eheh) servers.
> We probably need to be able to store different type of devices in a
> database:
> 
>   * access points (meaning stuff like ubiquiti NanoStation M5 - what's
>     the most correct name?)
>   * servers (a very expensive brand new machine :D for example)
>   * routers (yes.. a nanostation is also a router.. it's a tricky
>     business this one)
>   * more stuff? managed switches?
> 
> Making different database tables would mean duplicating relations with
> interfaces and ip addresses.
> Maybe this stuff should all go on a single table called "device" and we
> should have "types" or "categories".
> 
I think that we need a common minimal but extensible type "device" or
something similar, so each devices can have also particular properties,
all other kind of stuff like servers, router switch ecc ecc should
inherit from this type or a subtype and that should be done easily by
the user who add the device,

so that devices will have properties and each property should have
get/set(if writable) method which tell to the mapserver how to handle
that property

an example could be the SSID the map server can get or set that value on
the device but it need to know how to do that for example:
<method name="get">
	<?bash
		#!/bin/bash
		ssh_shot $HOST '
		. /etc/functions.sh
		config_load eigennet
		local meshSSID
		config_get meshSSID wireless "meshSSID"
		echo $meshSSID
		'
	?>
</method>
<method name="set">
	<?bash
		#!/bin/bash
		ssh_shot $HOST "uci set eigennet.wireless.meshSSID=$1"
	?>
</method>


> *Routing protocol*
> a device might have more than one routing protocol, think a case in
> which a node functions as a bridge between 2 networks with different
> routing protocols.
> The routing protocol could be installed on a server or an access point,
> or any other machine that has enough resources to run it, that's why I
> advice to have a single table for devices.
> In my opinion routing protocols should be related to the device table
> and it should be possible to assign more than one to a single device.
> 

maybe you some devices like hotspot doesn't have that so i think this
should be out of the core too

my 2 cent
bye!