Remarks on the Work of Sugar

[Mikus Grinbergs]

[This does not fit the 'Subject:', but is still worth remarking.]

Walter wrote:
> 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 
panel light.

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 
anything) ?


mikus