Two general thoughts

Samuel Klein at
Wed Feb 20 01:25:21 EST 2008

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.


2008/2/19 Ricardo Carrano <carrano at>:
> 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
> Devel at

More information about the Devel mailing list