I like your clear cut goals Mr. Dionisi. I dont mind writing documentation if someone can clear cut explain what the hell we shooting for (as exemplified by yourself). As far as Vala goes, as I mentioned earlier I dont care lets program already. I hope we have some mathematicians on board because I would hate to waste my time programming something inefficient.
What I am hoping/looking for is: A base p2p network that can be implemented via adhoc/ap mode capable devices. I would like to see an infrastructure such that there is no requirement for an ISP meaning DNS, IP allocation, routing etc must be part of the infrastructure. I would like if the infrastructure can play nicely with the existing internet (meaning vpn over the net capabilities to link lets say my Bay area network with Mr. Dionisi's (guessing) Italian network in his home town). Each node(client/person) that connects to the network becomes a resource for the whole (routing dns records whatever maybe data?). Right now I think that the core functionality that we should be aiming for is to be able to create a wireless networks with friends/family/people that is efficient and can provide serverless dns and routing. Other existing programs such as lan messengers and smb or nfs can be used on the network. So quick summary = We need to get a serverless private(or not depending on whos connecting) wireless network infrastructure framework up and running. Reminder, I am the peanut gallery. On Mon, Mar 28, 2011 at 3:15 AM, Luca Dionisi <[email protected]>wrote: > I am trying to sum up what many were asking for in the previous thread > > 1) documentation describing in details the theory of the current > implementation of the python daemon. At least for the aspects that > differ from the old theory described in the old docs. > > 2) mathematical proofs. > > 3) specifics of the devices and environments that we want to support. > > 4) a clear definition of the key components of the software and their > interfaces, in such a way that we could go ahead with several > implementations. > > I am not going to answer right now. > > For the moment I just want to state my own intentions: > > a) I will contribute to the development of a Vala implementation. > b) I am focusing on targeting of a Debian system, such as the one > targeted by the freedombox project for example. Something like a > guruplug/sheevaplug. I believe that for such a target a Vala > implementation is a valid choice and I wouldn't call it a "desktop" > device. It could very well be the embedded of the next year. > c) my starting point is the current python implementation; I know for > sure that this implementation, having been at a certain point a > complete implementation of the old theory, has then evolved > implementing the modifications that we applied to the theory for the > last circa 2 years; I don't know anything about how much of the old > theory was fully implemented in the C version. > d) I am willing (if I actually see someone starting to hack on a > different implementation, say in C) to help in understanding what the > python implementation is doing on a particular piece of code and why. > > --Luca > _______________________________________________ > Netsukuku mailing list > [email protected] > http://lists.dyne.org/mailman/listinfo/netsukuku >
_______________________________________________ Netsukuku mailing list [email protected] http://lists.dyne.org/mailman/listinfo/netsukuku
