Alternative to Create a new wireless network
Reuben K. Caron
reuben at laptop.org
Mon Dec 7 21:04:52 EST 2009
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. 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.
Your thoughts?
Regards,
Reuben
(1) http://dev.laptop.org/ticket/9807
(2) http://dev.sugarlabs.org/ticket/1604
More information about the Devel
mailing list