Hi everyone,<br><div class="gmail_quote"><br>Here are two thoughts I would like to share.<br>
<br>A necessary disclaimer: My relation to this project is now more than one year long (and took many forms during this period). I am permanently impressed by what this group of people managed to do in such a short time. So, please, those who put time in reading this, do keep in mind that I am an admirer!<br>

<br>A second disclaimer: These comments are _not_ directly related to the use cases we are to build for our test week.<br><br>1 - Automation and user will<br><br>I note a clear bias to the first. Automation is fundamental in many instances. You don't want a user to make flow or congestion control during transmissions, to cite one example. But we don't need to make every decision on behalf of the children, because:<br>

- The XO is a construcionist educational device.<br>- When you automate you sometimes get in the way of the sovereign user will.<br>- When you automate you make you system more complex. More complexity means errors and problems.<br>

I believe automation should be applied less eagerly.<br>In practice this means:<br>- Connectivity method should happen at users choice. If some automation is necessary it should be easily overwritten by the user. The user should be free to select local mesh 1,2 or 3 (channels 1,6,11), school mode, access points, mpps or a  disconnected mode (yes, so we can put the radio subsystem to sleep with no worries) in a clear and easy way, through the user interface.<br>

- Presence mechanisms (totally related to the item above) should be selected by the user. If he is able to select a site in a browser, he should be able to select a jabber server, or to just stay with salut.<br>- Suspend and resume should be a user command and much less aggressive when it happens automatically.<br>
<br><br>2 - Infrastructure and non-infrastructure<br>
<br>I note a recent bias to the first. Infrastructure may complement XOs capabilities, no doubt about it. But we came to a point that an XO relies on external components to basic tasks. The problem here is that:<br>-  Infrastructure is not always present. Even if there is some infrastructure at the school there will probably be none at home.<br>

-  Infrastructure breaks, wears out and is stolen.<br>I believe the XOs must be functional with no infrastructure and augmented when there is infrastructure.<br>In practice this means:<br>- Salut is not less important than gabble<br>

- MPPs are not less important than School servers<br>- Peer to peer applications are not less important then client-server apps<br><br>Note: I chose "and" instead of "vs" on purpose, because things are complementary, not opposing.<br>

Hope this is somehow useful. Even if it is totally wrong it may be useful to clarify the ideas, I hope.<br><br>Regards,<br><font color="#888888">Ricardo Carrano<br>
</font></div><br>