[sugar] Greetings from New Hampsire

[Marco Pesenti Gritti]

On Thu, Oct 23, 2008 at 9:25 PM, Brendan R. Powers <brendan at resara.com> wrote:
> Greetings,
>
> 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.

Hello Brendan,

this is fantastic, welcome to the list!

> 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.

We are definitely interested to take a lot of these changes upstream.
As you might know there are several efforts going on to use Sugar
outside OLPC and some of the problems you mention below are common to
these other projects too.

I think Bernardo is going to setup an upstream trac instance next
week. It would be cool if you could start opening tickets there. We
can use them as a way to discuss the issues your run into and to
figure out solutions that can be taken upstream and benefit the
community as whole.

> 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.
>

Yup. I've been wondering about how to better allow to customize the
"shutdown" options. One possibility would be to use Gconf schemas.
Control panel pages are extensions in git master, so they can be more
easily added or removed.

> 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.

The next generation of the Journal will have much better POSIX
compatibility, which should help this use case. Even with the current
implementation though, I think it's possible to display the journal
contents through a web server, that people could browse from a
Windows/Linux computer. (Tomeu, in cc, should have more details about
this.)

> It would be interesting to see if we could launch sugar activities without running the entire sugar interface.

That's one of my medium term goals about compatibility with standard
desktop. I'm going to talk about it at xocamp. Contributions would
surely help to speed up the process :)

> Also, local media attached to thin client may pose a challenge, as the normal ways to search for and mount media are not available.

Can you elaborate on this? I'm not sure to understand what's the use
case exactly.

> 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.

I think GConf and sabayon has been successfully used for this kind of
customization, for the GNOME desktop. We might want to go down that
way as well.

> 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.

Do you mean that as an hard limit or a soft one (i.e. students would
see their class "by default" but would also be allowed to see anyone
else on the jabber server if they want to)? In other words, are you
worrying about scalability or about privacy?

> 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.

In git master, we have switched to GConf to store the preferences
(there is still a profile class but just for compatibility). Does that
work well enough for you? Or which problems do you think you will run
into?

> 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.

I'm excited as well! Please keep posting us about any question or idea
you come up with it. Either through the mailing list, the irc channel
or the weekly meetings!

Thanks,
Marco