[Nodedb-interop] Frontend for common node database

Tue Jul 12 12:58:32 CEST 2011

Hi ya all,

I am starting to think that all this schema talk is useful up to the point where we will need to actually do something with it.

After collecting all the data and schemas from all the Node databases, it is almost straight forward to create a “fit all” schema. Anyway putting some tables in a DB is almost easy. As a matter of fact some of us might be able to create closed eyes an almost correct basic structure that fits all.

On the other hand what I found in the last couple of days looking around our implementations  is that we have massive differences on what we call a node, a Backbone node, a client node, on the way we allocate IPs, routing wise, allocation of areas, so on and so forth. I might be wrong here but I need serious explanations especially on the guifi implementation, community habits and definitions. Slovenia’s implementation is built around meshing which also might not fit the model of Guifi and AWMN.

For me this might be a  barrier as basic logic is not the same and surely it is very difficult to incorporate all in one product. I am very eager to see a collective report on your business logic (I am not sure about this term) Clemens which proves me wrong or makes everything look a bit greener and compatible!

I have also some other thoughts about all this that might or might not be true.

I feel that most of us will not leave or “mess” with the schema or our applications since we are accustomed to it. I tend to believe that WiND fits like a glove to what we do here apart from some wish list goodies needed and bug fixing. If I put down features one by one and compare all the other implementations, I surely can live comfortably much better with the way this project is evolving with the added benefit that I am used to it.

Another consideration is that some will not have the developers power to do alterations to fit or integrate to the new schema.

Moreover in some cases further development of each local node DB carries on without committing to the tasks we set collectively as interop team. It is difficult to find a balance between making your own application excellent and committing to the external task of interop.

That said, there is a possibility that by the time we get a schema going, it might not just fit to our previous assumptions about a community (ok a bit extreme but can be true), it might be obsolete due to new developments of a better local solution, it might just be too little to fit around a complex and elaborate development that someone has put hours and hours into, or it might be too little to convince a developer to take into account if it does not offer something more.

The last one brings us to the factor of persuading people into all this. Although I believe that a common schema is a good exercise in getting to know each other, a good way in describing common issues that we have and setting common ground for our Databases, I also believe that it is pointless without a frontend that will be collectively developed by all of the communities. Further to a common schema, I would like to see a “Super” EU Node database that will have taken in consideration all the known DB schemas around eu, capable of importing data or even replacing completely the solutions we use now. If we need to make something compelling we have to make it compelling too.

It will be a shame to waste powerful developers in creating schemas, interface bridges and multiple frontends solutions to the “same” problem, rather than taking an extra step and developing collectively a new powerful tool. The extensibility, modularity, plugability etc. should be solvable problems of that new application as a whole and not of the schema I believe. Those in my opinion will have to be backwards compatibility considerations rather than extensibility and modularity issues. No one with a sufficiently good node database application will take any notice of this new schema if he has no good application around it to look up to and realize it’s new benefits or goodies. At least this application should offer some tools.

Also once we come up with a magic CWN DB schema, we cannot rely on what others will do with this schema or what might be possible to do with it, but we need ourselves to find, recruit, coach if needed and commit human assets to a project described above to make some sense out of all this.

The chase of APIs, database schemas, Community Habits so on and so forth are good for “starters” but I think the plunge has to be taken.

I don’t know. Many thoughts go around my head in a mixed I guess order (yea right)  and I see an Academic sort of process-conversation going on for months now without any practicality built around it and no distant tangible goal. 

A new common Application IS tangible for me (maybe only for me), a database schema and a “business logic” analysis is a lot of steps before that. Maybe next to useless without the first so it would be great if we had something like that in the distant horizon and stress more on finding resources for building that application or set of tools rather than anything else. 

Let’s study some community logic, define the schema carefully, build a features comparison map between all the apps we already have and completely skip the rest into developing a new era set of tools or applications. I see no other justifiable and reasonable way in continuing this otherwise. How about that?

Regards,

JB

P.S. Sorry for my long mail. 

From: (spam-protected) [mailto:(spam-protected)] On Behalf Of Ramon Roca
Sent: Tuesday, July 12, 2011 1:06 AM
To: (spam-protected)
Subject: Re: [Nodedb-interop] Frontend for common node database

I agree on almost everything. Any database should have frontends, and as many tools around this as possible. Generally speaken, the people choose a nioce framework development tool, builds apps with it, and by that is more than enough, but for this purpose this is not the right approach, this is what led every community to reinvent the wheel again and again and blocked for reusing our respective developments between us.

Thinking for an effective and long-term solution we should (more or less in order)

1.	Define a common database schema, extendeable and able to consolidate information for all of us, interoperable.
2.	Have a well defined API to interact with it through several ways, i.e. SOA, etc.
3.	Build a database interface to interact with it, but also connect existing apps to do the same, as well other can build other interfaces.

I know that by building on this way, will will have to wait much longer for getting practical results, but ? I'm convinced that this is the right path, and wish the best inspiration to all of you who are already contributing with your effort ;)

Thanksfully,
Ramon.

Al 11/07/11 22:32, En/na Mitar ha escrit: 

Hi!

(Ups, pressd send too soon.)

We are already working on something like this with our 3.0 version of
nodewatcher.

http://dev.wlan-si.net/wiki/Nodewatcher/Registry

For me concerning AWMN everything is clear at the moment (thanks for your 
emails :D) so we don´t need to skype today. I will use your answers now to 
finish my "business model" of awmn/WiND now and will ask you to take a look at 
this document when I have finished it.

Could all this collected data from different networks be shared? I
believe this would be great stuff to read. Maybe put them on the interop
wiki?

Mitar

_______________________________________________
Nodedb-interop mailing list
(spam-protected)
https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/nodedb-interop/attachments/20110712/a59791dc/attachment.html>