<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1897276954;
mso-list-template-ids:-479151434;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EL link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi ya all,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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!<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have also some other thoughts about all this that might or might not be true.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another consideration is that some will not have the developers power to do alterations to fit or integrate to the new schema.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>JB<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>P.S. Sorry for my long mail. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> nodedb-interop-bounces@lists.funkfeuer.at [mailto:nodedb-interop-bounces@lists.funkfeuer.at] <b>On Behalf Of </b>Ramon Roca<br><b>Sent:</b> Tuesday, July 12, 2011 1:06 AM<br><b>To:</b> nodedb-interop@lists.funkfeuer.at<br><b>Subject:</b> Re: [Nodedb-interop] Frontend for common node database<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'>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.<br><br>Thinking for an effective and long-term solution we should (more or less in order)<o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Define a common database schema, extendeable and able to consolidate information for all of us, interoperable.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Have a well defined API to interact with it through several ways, i.e. SOA, etc.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Build a database interface to interact with it, but also connect existing apps to do the same, as well other can build other interfaces.<o:p></o:p></li></ol><p class=MsoNormal>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 ;)<br><br>Thanksfully,<br>Ramon.<br><br>Al 11/07/11 22:32, En/na Mitar ha escrit: <o:p></o:p></p><pre>Hi!<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>(Ups, pressd send too soon.)<o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>We are already working on something like this with our 3.0 version of<o:p></o:p></pre><pre>nodewatcher.<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre><a href="http://dev.wlan-si.net/wiki/Nodewatcher/Registry">http://dev.wlan-si.net/wiki/Nodewatcher/Registry</a><o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>For me concerning AWMN everything is clear at the moment (thanks for your <o:p></o:p></pre><pre>emails :D) so we don´t need to skype today. I will use your answers now to <o:p></o:p></pre><pre>finish my "business model" of awmn/WiND now and will ask you to take a look at <o:p></o:p></pre><pre>this document when I have finished it.<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>Could all this collected data from different networks be shared? I<o:p></o:p></pre><pre>believe this would be great stuff to read. Maybe put them on the interop<o:p></o:p></pre><pre>wiki?<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Mitar<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>Nodedb-interop mailing list<o:p></o:p></pre><pre><a href="mailto:Nodedb-interop@lists.funkfeuer.at">Nodedb-interop@lists.funkfeuer.at</a><o:p></o:p></pre><pre><a href="https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop">https://lists.funkfeuer.at/mailman/listinfo/nodedb-interop</a><o:p></o:p></pre><p class=MsoNormal><o:p> </o:p></p></div></body></html>