On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers <[EMAIL PROTECTED]>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 > www.resara.com > > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar >
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
