[Interop-dev] Common API

NicoEchániz (spam-protected)
Sat Nov 17 08:53:57 CET 2012


On 11/01/2012 03:42 PM, Ralf Schlatterbeck wrote:
> On Tue, Oct 30, 2012 at 11:34:53AM -0300, NicoEchániz wrote:
>> On 10/30/12 06:37, Mitar wrote:
>>> Hi!
>>>
>>>> What about the others? do you have a different/contradictory minimal
>>>> node data representation in mind or at work?
>>>
>>> Have you checked schemas of others listed here:
>>>
>>> http://interop.wlan-si.net/
>>>
>>> There was also one common schema Aaron and other worked on.
>>
>> I've looked at them. I was planning on analyzing them to find out what
>> minimal data models they share, but if Aaron and others have already
>> worked on this, I'd like to see the results. Are they published online?
> 
> We've analyzed them and came up with our model that should cover most of
> it -- this is still work in progress and we haven't implemented a
> superset yet, in particular what people call a "Zone" is very different
> in different networks...
> 
> A graphical representation (semi-automatically generated from our object
> model) is on our github project page at 
> 
> https://github.com/FFM/FFM
> 
> This took much input from an SQL schema by Aaron and others which is
> linked from the NodeDatabase page on the wiki above:
> 
> http://interop.wlan-si.net/wiki/NodesDatabase
> 
> schema:
> 
> https://github.com/aaronkaplan/commonNodeDB

(back from Colombia[0]... my delayed answer to this thread)

I've found both Aaron's SQL schema and the FFM graph most interesting. I
believe they cover much detail. Together with the CNML structure they
are a great basis for general discussion on the matter.


However, appart from the data model, I'd like to know how each of us
imagines inter-operation actually taking place. Do we want to develop
software that we can all implement?, or do we want our different
solutions to just interoperate, and if so, in what manner? Do we want to
map other networks in our own mapping services? Do we want to have a
world map service that can collect or receive data from each CWN database?


Our effort in this area at the moment is focused on gathering as much
automatically generated data as possible from node/devices, so that the
only human intervention needed for a minimal representation of our
networks' status will be node naming and positioning. All other data:
radios, interfaces, mac addresses, hardware, firmware, routing data,
link state, etc. should be pushed by the devices themselves. Everything
else (antenna type, actual address, people involved, etc.) would be
optional in our model.


Guido posted a minimal preview URL[1](IPv6 only) of our current
prototype, which is the product of a few day's work, and as such, very
minimalistic, unsecure and buggy :)  but it's serves it's purpose of
testing the technologies involved (mainly CouchDB, Backbone.js and
OpenLayers).

We are aiming at this particular type of solution because our team is
focused on helping deploy small community networks around Latin America,
targeting small towns where geeks are hard to find and so every
component of our network design is based on minimal user/admin
intervention and supported by short intensive training workshops.

We are also aiming at a map solution that will scale from a small town
to a large group of networks with unattended replication between
federated servers (this comes for "free" with the chosen
technologies[2]); if you install[3] an altermap clone[4] and set it to
replicate from another, it will "just work" (again... no security ATM).



So... in particular, I'd like to know what you guys are thinking would
be the common objectives of this "interop layer", apart from the common
database schema.



Cheers,
NicoEchániz



[0] http://blog.altermundi.net/article/santas-pelucas-voladoras-batman/

[1]
http://tilc.red.quintanalibre.org.ar:5984/altermap/_design/altermap/index.html

[2] http://wiki.apache.org/couchdb/Replication

[3] https://colectivo.altermundi.net/projects/altermap/wiki

[4] hg clone http://bitbucket.org/nicoechaniz/altermap




















More information about the Interop-dev mailing list