Hello Ricardo, I agree with both of your points. The best network applications will work peer to peer, and not depend on (but will be enhanced by) the presence of servers. And I would add that where automation is implemented, it should be clear how to turn (every aspect of) it off.
SJ 2008/2/19 Ricardo Carrano <[EMAIL PROTECTED]>: > Hi everyone, > > Here are two thoughts I would like to share. > > 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! > > A second disclaimer: These comments are _not_ directly related to the use > cases we are to build for our test week. > > 1 - Automation and user will > > 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: > - The XO is a construcionist educational device. > - When you automate you sometimes get in the way of the sovereign user will. > - When you automate you make you system more complex. More complexity means > errors and problems. > I believe automation should be applied less eagerly. > In practice this means: > - 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. > - 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. > - Suspend and resume should be a user command and much less aggressive when > it happens automatically. > > > 2 - Infrastructure and non-infrastructure > > 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: > - Infrastructure is not always present. Even if there is some > infrastructure at the school there will probably be none at home. > - Infrastructure breaks, wears out and is stolen. > I believe the XOs must be functional with no infrastructure and augmented > when there is infrastructure. > In practice this means: > - Salut is not less important than gabble > - MPPs are not less important than School servers > - Peer to peer applications are not less important then client-server apps > > Note: I chose "and" instead of "vs" on purpose, because things are > complementary, not opposing. > Hope this is somehow useful. Even if it is totally wrong it may be useful > to clarify the ideas, I hope. > > Regards, > Ricardo Carrano > > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
