[Interop-dev] Common API

Tue Jul 30 10:28:06 CEST 2013

Hi guys,

this email might be too long for some so I want to get this message
delivered to you first:

/*"WHO HAS A WORKING NODE DB WITH A RESTFUL API AND IS INTERESTED TRYING
TO IMPLEMENT INTEROPERABILITY WITH NODESHOT PLEASE CONTACT ME AND SEND
ME THE DOCUMENTATION FOR YOUR API"

*/Sorry for the uppercase bold text ... eheh :-P

Onto the technical things:

I just developed a mechanism that implements Interoperation between
nodeshot and a different 3rd party application with a different API.
To synchronize the two databases a synchronizer class must be written.
But my goal is to achieve base classes and mixins so that as little code
as possible will be needed.

(code is here:
https://github.com/nemesisdesign/nodeshot/tree/refactoring/nodeshot/interoperability
and synchronizers are here
https://github.com/nemesisdesign/nodeshot/tree/refactoring/nodeshot/interoperability/synchronizers
)

Example:

*Application A*: Nodeshot2
*
**Application B*: CitySDK Tourism API http://citysdk.ist.utl.pt/

Application *A* sends all his POIs to Application *B* and costantly
updates *B* when something on *A* changes.

The inital synchronization can be done manually with a command, but can
also be scheduled to run daily, just to check that everything is ok.

Example:
python manage.py synchronize <slug-of-layer>

And all the local records in Nodeshot are sent to CitySDK.
If the command is run again it will check for difference and perform
adds, updates or deletes only if necessary.

Afterwards, when creating, editing or deleting a record from Nodeshot2,
the corresponding record is created, edited or deleted on CitySDK, this
is possible thank to the fact that Nodeshot2 stores the ID of the record
displayed in the CitySDK API.

*Another use case*

Application *A*: Nodeshot2

Application *B*: OpenWISP

Nodeshot2 collects the data of various OpenWISP-monitoring instances,
and serves only as a repository of all the hotspots.

We are using this functionality at work to collect the public hotspot
data of all the public wifi network my group manage (like 13 cities or
provinces), in order to release them in open-data format soon.

It's very simple, synchronizers are used just to pull data from external
XML files into a local DB and everything is updated periodically

*What's next?*

These cases works nicely, but they are first attempts.

My next attempt will be to try to implement also the possibility to use
a method similar to Active Resource, for those who don't know
Ruby/Rails, Active Resource is a great library written in ruby that
permits to consume an HTTP RESTful API like a database, so you can use
the same ORM method you would with your own database, but instead of
making queries to a DB, it will make queries via HTTP.

There's something very similar for django, called "Django ROA (Resource
Oriented Architecture)" which I haven't tried yet, but looks very good
to me:
http://code.larlet.fr/django-roa/wiki/Home

So my next step will be try avoiding to save the external nodes in the
local DB at all, but this can be performed only if the API used is the
same or very similar, unless i can figure out how to implement a kind of
translator.

The first attempt will be with nodeshot2 itself, that is to make
nodeshot2 able to speak with other nodeshot2 instances. Easier said than
done, I don't have a clue of handle different settings of different
applications, node ownership, access level and all that stuff. But who
cares, I'll start and eventually figure it out.

And hey, I started thinking there cannot be real interoperability
without the interoperable applications doing a kind of federated
authentication system with oauth or something.
Think about it.

*Federico Capoano*
Web Designer & Web Developer
Portfolio/Blog: nemesisdesign.net <http://nemesisdesign.net>
Twitter: @nemesisdesign <http://twitter.com/nemesisdesign/>
PGP Key ID: 308BD46E

Il 11/17/2012 08:53 AM, NicoEchániz ha scritto:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Interop-dev mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20130730/e8a5dc4d/attachment.html>