On Dec 7, 2009, at 9:04 PM, Reuben K. Caron wrote: > Daniel, > > Since we've run into problems with creating ad-hocs networks on the XO > 1.5 (1) (2), I've been thinking about this functionality, the change > in UI behavior and perhaps the decrease in usability and I don't like > it. I believe it is clunky to have children create their own > networks..Who designates who creates the network? Why do I have to > join that network? Why can't I make my own network and have them join > me, etc.. All of this is aside from the technical limitations of which > channel does my network get created on. Does the user specify channels > 1, 6, or 11 when creating the network, or does the channel randomly > get set? If randomly set, how do we avoid channel overlaps and > interference. > > To ease all of this and maintain a similar UI, what if we: > > -Create three faux "Mesh Channel #" icons in the Network view > -When the child wants to join a mesh network they will select one of > the networks > -Upon selection: the XO will: 1. Scan to see if that ad-hoc network > already exists and 2. if it does not exist the XO will create the > network allowing other children to join it. > > The one pitfall of this idea, and I'm not sure how much of an issue > this would be, is also the pitfall of ad-hoc networks...when the > initiator of the ad-hoc network leaves the network fails.
I don't understand why you say this. AFAIK, this is not the expected behavior of ad-hoc networks. > When the > network has a respective name it is a bit more obvious when that > person has left and the reason why the network has failed, this would > not be the case given the anonymity of a "Mesh Network #." A more long > term solution to this problem may be for the XO to sense the loss of > the initiator and recreate the network. In this case, the first XO to > sense the loss of the network after some period of time would check if > another XO has already setup the network, if not the XO would create > the network or join the new one if it already exists. > > Aside from the one pitfall, I think it would be really beneficial to > maintain the same UI and appearance of functionality. Further > development in this area may also help us get MPP back, at least at > the software level. There is no question that we want to avoid changes in this UI --- this is already one of the more complex actions that we expect teachers/students to do. Changing it mid-stream would be very confusing. wad _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
