No subject

bogus at bogus at
Sat Oct 25 06:33:42 EDT 2008

wanting it to do, unless you use some other thin client technology.

Kind Regards,
David Van Assche

On Sat, Oct 25, 2008 at 3:30 AM, David Farning <dfarning at> wrote:
> On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers <brendan at>
> wrote:
>> Greetings,
> Hey Brendan,
> Welcome to the list!
>> Our company and developers are interested in getting involved with the
>> development community for Sugar. We deploy Linux desktop solutions in
>> schools in the United States via thin client and fat client methods. We
>> believe that Sugar's collaboration tools, journal,  and other features could
>> be very appealing to younger grade (elementary and middle school) students
>> and teachers. Several of our schools are interested in using Sugar in the
>> classrooms already on their thin client desktops.
> Very cool, we are interested in making Sugar available to a wider audience!
>> We have the Ubuntu packages running fine, but it is evident that there are
>> changes that should be made to Sugar when its not being used on the OLPC.
>> Some of the challenges for deploying Sugar on desktops in a school
>> environment are different than using it on standalone OLPCs, which need to
>> be overcome for Sugar to take a major foothold independent of the OLPC.
>> Below we have listed some of the issues we think need to be addressed based
>> on our experience with working in schools.
> What would be your preferred work flow? One thought would be set up a
> client/server git tree for client/server development.  Then, the work you,
> and others do, can be pulled into the main tree.  In the near future,
> SugarLabs will be hosting a git server. Either we can host a C/S tree or you
> can host it yourself.
> Do you use LTSP as the basis for your client server technology?
>> The technical challenges we see are mostly problems integrating sugar into
>> a thin client architecture, and into the networks of schools. One of the
>> most immediate changes we will need to make are customizations to the
>> interface. For example, thin clients may not need the shutdown and reboot
>> options, and need a logout option. There are other customizations that we
>> may need to make, such as adding or removing items from the control panel.
>> These sorts of changes are small, and once done will allow people to deploy
>> sugar in a small classroom environment.
>> On larger installations, schools will want sugar to integrate with there
>> existing file and print servers, as well as some centralized administration
>> of the sugar interface. Ideally, the journal and datastore would be stored
>> on the file server in such a way as to allow teachers to access the saved
>> activities from a normal Windows or Linux computer. It would be interesting
>> to see if we could launch sugar activities without running the entire sugar
>> interface. Also, local media attached to thin client may pose a challenge,
>> as the normal ways to search for and mount media are not available.
>> Another important aspect of larger sugar deployments would be the ability
>> of admins to customize the user interface. For example they may not want
>> users to have access to the control panel, or may want to set up the list of
>> activities per grade, and prevent users from installing there own
>> activities.
>> One of the most interesting aspects of sugar is its collaboration
>> features, but this too poses some difficulties. In multi classroom
>> environments its not clear how the collaboration would work. Ideally there
>> would be one jabber server for the entire network. This would mean that
>> every student on the network could see every other student on the network,
>> when the desired behavior may be to only see the students in the current
>> class.
> Using the Jabber server in a non-xs environment is a issue on which we are
> only just now starting to focus.  We have a lot of work to do.
>> These are some of the issues were thinking about. We could solve most of
>> these problem by creating our own custom build of sugar with the patches
>> needed to integrate with our current software. However, we would rather work
>> with the community to create solutions to the problems. For example, one of
>> the things we would like to do is to extend the profile class to allow for
>> multiple back ends, as well as the ability to store generic settings. This
>> would allow us to integrate some of the important profile settings, such as
>> the jabber server, into our management software, while at the same time
>> keeping a consistent API and keeping our code separate from the sugar tree.
> Thanks for you willingness to work with us!  By Monday, Marco our lead
> developer will be able to answer you questions in more detail.
> thanks
> david
>> We are very excited about the possibilities that sugar provides. We look
>> forward to contributing to this project, and we are interested in your
>> thoughts about these issues.
>> -----------------------
>> Brendan Powers
>> Resara LLC
>> 1.888.357.9195
>> _______________________________________________
>> Sugar mailing list
>> Sugar at
> _______________________________________________
> Sugar mailing list
> Sugar at

More information about the Sugar-devel mailing list