No subject

[bogus at does.not.exist.com]

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

Kind Regards,
David Van Assche
www.nubae.com



On Sat, Oct 25, 2008 at 3:30 AM, David Farning <dfarning at sugarlabs.org> wrote:
>
>
> On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers <brendan at resara.com>
> 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
>> Sugar at lists.laptop.org
>> http://lists.laptop.org/listinfo/sugar
>
>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
>