From (spam-protected) Sun Jul 3 11:43:39 2011 From: (spam-protected) (Clemens John) Date: Sun, 3 Jul 2011 11:43:39 +0200 Subject: [Nodedb-interop] Research on Open Wireless community Message-ID: <201107031143.40265.clemens-john@gmx.de> Hi, for my research on different node databases I´m interested in general information about the networks behind the databases so I want to ask each network some questions. For me it would be interesting if you would like to add any uestions? Then please send me an email. In the next day´s I´m going to try to interview one person of each network so I would be happy if you let me know who to interview. For Athen I have Joseph, for Funkfeuer Aaaron, Guifi.net is Miguel I think and Oldenburg is me. Who can I also interview? Mitar for Slowenien? Now the quesions I have until now: *what is the main goal of the network? *number of nodes: *which hardware do you use? *which routing protocols do you use? *Do you have accesspoints open for the general public? *general wireless concept: *special features (firmware or network design) *how do you connect nodes that cannot see other nodes wireless? *does a client need special software to fully use the network? *how do you get the network stable? *what is you method to get high bandwidth available? *how do you handle high traffic? How do you handle traffic pigs? *do you have a backbone network? *what do you use the backbone for? *how does the backbone network work? Which hardware do you use for this? *What are the steps involved when someone wants to join the network? Please describe as detailed as possible... every step *how do you provide Internet access? *how do yo solve legal problems if someone does something illegal with a open internet connection? *Who pays for the Internet uplink? *Are there any rules which traffic is allowed or which traffic you tolerate in your network? *Which rules are this? *Do you enforce the Pico Peering Agreement? How? *Who setups up the nodes? *Do you have paid people? *how do you handle money? *What is the financial sustainability model? Do you have one? *What expenses does the association / network have? How are these costs covered? *common problems in your network *Possible future directions for your network *Possible future directions for your node administration software (aka node database) Regards Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From (spam-protected) Sun Jul 3 17:36:28 2011 From: (spam-protected) (Mathias Mahnke) Date: Sun, 03 Jul 2011 17:36:28 +0200 Subject: [Nodedb-interop] Research on Open Wireless community In-Reply-To: <201107031143.40265.clemens-john@gmx.de> References: <201107031143.40265.clemens-john@gmx.de> Message-ID: Hi Clemens, On Sun, 3 Jul 2011 11:43:39 +0200, Clemens John wrote: > Who can I also interview? we can also support - Mecklenburg-Vorpommern around Rostock / Germany ("Opennet Initiative e.V." - http://www.opennet-initiative.de/). Let me know, if we can help out. > Now the quesions I have until now: > *what is the main goal of the network? > *number of nodes: > *which hardware do you use? > *which routing protocols do you use? > *Do you have accesspoints open for the general public? > *general wireless concept: > *special features (firmware or network design) > *how do you connect nodes that cannot see other nodes wireless? > *does a client need special software to fully use the network? > *how do you get the network stable? > *what is you method to get high bandwidth available? > *how do you handle high traffic? How do you handle traffic pigs? > *do you have a backbone network? > *what do you use the backbone for? > *how does the backbone network work? Which hardware do you use for this? > *What are the steps involved when someone wants to join the network? > Please > describe as detailed as possible... every step > *how do you provide Internet access? > *how do yo solve legal problems if someone does something illegal with a > open > internet connection? > *Who pays for the Internet uplink? > *Are there any rules which traffic is allowed or which traffic you > tolerate in > your network? > *Which rules are this? > *Do you enforce the Pico Peering Agreement? How? > *Who setups up the nodes? > *Do you have paid people? > *how do you handle money? > *What is the financial sustainability model? Do you have one? > *What expenses does the association / network have? How are these costs > covered? > *common problems in your network > *Possible future directions for your network > *Possible future directions for your node administration software (aka > node > database) Do you need it in English or German? Any preference? Regards Mathias From (spam-protected) Sun Jul 3 23:51:21 2011 From: (spam-protected) (L. Aaron Kaplan) Date: Sun, 3 Jul 2011 23:51:21 +0200 Subject: [Nodedb-interop] Research on Open Wireless community In-Reply-To: References: <201107031143.40265.clemens-john@gmx.de> Message-ID: IMHO I think english would be easier... >> > > Do you need it in English or German? Any preference? > > Regards > Mathias > > _______________________________________________ > Nodedb-interop mailing list > Nodedb-interop at lists.funkfeuer.at > https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 243 bytes Desc: This is a digitally signed message part URL: From (spam-protected) Tue Jul 5 19:56:31 2011 From: (spam-protected) (Clemens John) Date: Tue, 5 Jul 2011 19:56:31 +0200 Subject: [Nodedb-interop] Frontend for common node database Message-ID: <201107051956.35456.clemens-john@gmx.de> Hi Joseph, Sorry that I´m late today. You where not online in skype some minutes ago so I started to continue by email where we have been interupted by my damn internet connection yesterday. First: I read all your last emails now, they are verry detailed and I really can use them. Thank you. I will also send a copy of this to the nodedb-interop list because it may be interesting for the people who are redaing this list too and gives the opportunity to start an open discussion. Your question was if the common node database will have a frontend. I really would like to see a frontend, but finishing a frontend is not the main goal of this GSoC. The main goal of this GSoC is, to get to know how all the existing node databases work, how they are designed, to get to know how each community works and then to design a database shema that fullfills everyones needs. In this shema features will be marked as "must have", "should have" and "may have" to see which features are basic features and which features will be outsourced maybe in plugins or which features have low priority. (I´m not shure about this point) Then we will write conversion mechanisms so that the data can be imported and exported from other node databases to the common node database. As a second verry importand point is, that on top or with the help of the sheme design we want to design an api. We do not want the data of each community in one big database, but we want the data of each community to be available in a common format so that people can build applications which can use the data (a global map for example or image builder). I´m not really shure if this will be possible, but my personal goal is, that each community does not need to make the software work twice. In Germany we have a lot independent Freifunk Communitys (think you know this) and every community does the work on a database or other tools twice because no one can/wants to use the tools designed by other communitys because they are not good enough or something like this. So I would be verry happy to see a frontend for the common node database and I would like to participate in the development also after GSoC. Aaron is planning a code sprint (or "only" a meeting?) in August. I have already seen that you are planning to rewrite WiND in version 2. Maybe this can be the point to merge development and to design something that fits the need of every community? As developer of our node database (Netmon, http://netmon.freifunk- ol.de) I would be verry happy if this can happen. In the introduction mail Aaron already wrote that at the end (at the end of evaluating how the atabases and the communitys work) we will have to discuss with the networks the steps which would be needed to replace the current DB with a commonNodeDB. If you have ideas on this you are welcome. 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. Regards Clemens P.S. Aaron and Amir: if I got something wrong please correct me ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From (spam-protected) Mon Jul 11 22:30:42 2011 From: (spam-protected) (Mitar) Date: Mon, 11 Jul 2011 22:30:42 +0200 Subject: [Nodedb-interop] Frontend for common node database In-Reply-To: <201107051956.35456.clemens-john@gmx.de> References: <201107051956.35456.clemens-john@gmx.de> Message-ID: <4E1B5D72.30301@tnode.com> Hi! > Your question was if the common node database will have a frontend. For nodewatcher system Kostko has developed an automatic system which generates the frontend based on the schema. Very heavy stuff, supporting customized default rules, dynamic forms based on selected fields, value validation and error reporting and many more. > Then we will write conversion mechanisms so that the data can be > imported and exported from other node databases to the common node > database. I am not sure if this is viable? Isn't it the idea that our node database systems adapt this schema so that real-time integration of different components can occur? Not that we have just one-time translation? (OK, if all systems start using this schema also internally, but I doubt if this is possible.) One more thing we should define is probably if we are talking about common schema for data exchange (so read only) or also for data updating. Like collecting all data to a common world map of nodes would be read only operation. But being able to have one frontend to many different node database systems would need also updating (and some API). I am thinking that we are mostly all the time thinking about the first one only, true? > I´m not really shure if this will be possible, but my personal goal is, that > each community does not need to make the software work twice. Personally (but I would not like to repeat myself here too much) I believe that this is not enough and that we also need to make software itself modular and with interchangeable components. So that we can collaborate also on software development. Not that everybody will again write their own map solution, only with same schema. > I have already seen that you are planning to rewrite WiND in version > 2. Maybe this can be the point to merge development and to design > something that fits the need of every community? We are already working on something like this with our 3.0 version of nodewatcher. As developer of our node database (Netmon, http://netmon.freifunk- > ol.de) I would be verry happy if this can happen. > > In the introduction mail Aaron already wrote that at the end (at the end of > evaluating how the atabases and the communitys work) we will have to discuss > with the networks the steps which would be needed to replace the current DB > with a commonNodeDB. If you have ideas on this you are welcome. > > 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. > > Regards > Clemens > > P.S. Aaron and Amir: if I got something wrong please correct me ;) > > > > _______________________________________________ > Nodedb-interop mailing list > Nodedb-interop at lists.funkfeuer.at > https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop From (spam-protected) Mon Jul 11 22:32:08 2011 From: (spam-protected) (Mitar) Date: Mon, 11 Jul 2011 22:32:08 +0200 Subject: [Nodedb-interop] Frontend for common node database In-Reply-To: <4E1B5D72.30301@tnode.com> References: <201107051956.35456.clemens-john@gmx.de> <4E1B5D72.30301@tnode.com> Message-ID: <4E1B5DC8.5040205@tnode.com> 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 From (spam-protected) Tue Jul 12 00:06:25 2011 From: (spam-protected) (Ramon Roca) Date: Tue, 12 Jul 2011 00:06:25 +0200 Subject: [Nodedb-interop] Frontend for common node database In-Reply-To: <4E1B5DC8.5040205@tnode.com> References: <201107051956.35456.clemens-john@gmx.de> <4E1B5D72.30301@tnode.com> <4E1B5DC8.5040205@tnode.com> Message-ID: <4E1B73E1.5020008@guifi.net> 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 > Nodedb-interop at lists.funkfeuer.at > https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Tue Jul 12 12:58:32 2011 From: (spam-protected) (Joseph Bonicioli) Date: Tue, 12 Jul 2011 13:58:32 +0300 Subject: [Nodedb-interop] Frontend for common node database In-Reply-To: <4E1B73E1.5020008@guifi.net> References: <201107051956.35456.clemens-john@gmx.de> <4E1B5D72.30301@tnode.com> <4E1B5DC8.5040205@tnode.com> <4E1B73E1.5020008@guifi.net> Message-ID: <00ee01cc4082$a44fef90$ecefceb0$@awmn.net> 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: nodedb-interop-bounces at lists.funkfeuer.at [mailto:nodedb-interop-bounces at lists.funkfeuer.at] On Behalf Of Ramon Roca Sent: Tuesday, July 12, 2011 1:06 AM To: nodedb-interop at lists.funkfeuer.at 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 Nodedb-interop at lists.funkfeuer.at https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop -------------- next part -------------- An HTML attachment was scrubbed... URL: