Remarks on the Work of Sugar
mikus at bga.com
Wed Jul 23 13:30:44 EDT 2008
[This does not fit the 'Subject:', but is still worth remarking.]
> It is clear from even a casual review of the devel and sugar lists and trac
> that much of the frustration experienced by both users and developers
> resides not in the details of, for example, dbus or Python, but rather
> in more catastrophic and unpredictable failures of the network ...
My comment arises out of my dissatisfaction with the use of the
"network lights" on the front panel of the OLPC. My problem is that
although "how the OLPC communicates" has been written about, I have
been UNABLE to form a clear picture of how 'destinations' interact.
[The current use of the lights is confusing and uninformative. I
think a light being off should show the corresponding connectivity
does not exist. Flashing could show that connectivity is being
(re)attempted; and pulsing could show "this connectivity is being
actively used at this moment".]
I can identify five different 'destinations' for OLPC communication:
(1) To another XO, via the mesh ("under the tree")
(2) To the "school server", via the mesh [e.g., no AP "relay"]
(3) To another user (XO?), via an AP relay [today - via jabber]
(4) To the "school server", via an AP "relay"
(5) To a (non-school) server on the internet, via an AP [wget]
It is difficult to "intelligently" map the states of these five
modes onto just two lights (all that are available on the XO-1).
What "from the lights" information will best guide the behavior of
the kid using the XO?
I think it makes a difference to the kid's future behavior if he is
connected to the internet or not -- that makes showing "AP status" a
good candidate for a front panel light.
I also think the kid would like to see at a glance whether he can at
this instant fetch_from/save_to the school server -- in my opinion
showing "school server status" is a good candidate for using a front
Then, for instance in "under the tree" situations, the kid wants to
know whether he can communicate with his buddy. Right now it
involves an explicit invocation of Neighborhood View to check on
that -- a good use for a THIRD light would be to show "mesh status".
[With only two lights available, perhaps a Control Panel function
could assign what those lights show, Then G1G1 users would likely
not ask to see the "school server" status.]
And clearly written DOCUMENTATION would be helpful -- particularly a
"guide for connecting to 'destinations"". For instance, HOW does
switching communication to the school server between mesh-IP-address
access and AP access (presumably with an internet-IP-address) work ?
And if buddies were formerly accessed through the mesh, but
starting at 1 p.m. are to be accessed through the school server
jabbber - what needs to happen at the XO (does the kid have to do
More information about the Devel