> Milestone 1.0 is perhaps a little too ambitious -- I suggest you should start > by fixing just one mode of operation, in order to get a working prototype > as soon as possible. For example, you could start by just making it > possible to join an existing mesh, while creating your own mesh should be > milestone 1.1.
I was thinking this as well. It would make a bit more of an even mode of development - in Milestone 1.0 we would have ad-hoc working (maybe not fully auto-configured) and a basic GUI for connecting to mesh networks with the tutorials and connection wizard, editing olsr.conf, etc. In Milestone 2.0 we add all of the support for GPS, nameservice, location sharing, showing mesh topology overlayed on Google maps, etc. For example, you could start by just making it possible to join an existing > mesh, while creating your own mesh should be milestone 1.1. I like this idea. I think setting up temporary mesh will be a bit more difficult to put together (since we assume no technical knowledge and need autoconfig tools and a wizard to walk the user through setting one up the first time - then use this as the default unless they want to change it for some reason), so perhaps we should include this in another Milestone. Milestone 1.1 (or whatever we like to call it) could provide a couple more features like temporary mesh networks and some added usability (tutorial, wizard, autoconfig tools like AHCP). One thing you may want to keep in mind is to make as much of the software > you develop routing-protocol agnostic. Yes, this has been the idea from the very beginning. We want to expand the routing protocols that MeshApp can support, and make it very easy to include support for protocols other than olsr. It would be cool to have MeshApp load routing protocols in manner similar to how olsr loads plugins. I believe the dot(1) format is usually sufficient as an abstract layer to > describe the networks (for visualization purposes). It is very easy to > parse, you get a first impression by running the graphviz tools and of > course you can visualize it via Java on the phone itself if you want that to > do that (but it might make sense to limit the graph because the screen is so > small. Like just to show the 2 hop neighbours). Interesting. How can we do visualization via Java? Could you elaborate on this? Mind you, Babel doesn't have full topology information, just reachability > data. So being fully protocol-agnostic implies being able to reconstruct > the missing data. > As Mitar has already mentioned, when the routing protocol does not have full information topology (Babel, BATMAN, etc.) then MeshApp will just construct the topology that it knows. We discussed it as a possibility (at some point in the future, when we have good visualization tools and port Babel to MeshApp) that we could have an option to take a snapshot of the network topology at regular intervals. For instance, you walk around for an hour and take a snapshot of the mesh every five minutes and save the data - then load it up onto a computer later and see how the network changes (from the perspective of the mobile device) from different locations. I think a feature like this for routing protocols like Babel would be interesting. Oh, and happy learning Slovenian ;-) Hvala. ;-) I can navigate myself around the wlan-lj site pretty easily now. A lot of the words and grammar ideas in Slovenian are very similar to Russian, which is a language I know pretty well. For instance, "Podrobnosti" is (almost) exactly the same word in Russian. - Charles B.
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
