[Sugar-devel] Enhancing Sugar to support multiple users
pbrobinson at gmail.com
pbrobinson at gmail.com
Tue Sep 7 05:01:51 EDT 2010
On Tue, Sep 7, 2010 at 9:40 AM, Simon Schampijer <simon at schampijer.de> wrote:
> On 09/06/2010 03:40 PM, pbrobinson at gmail.com wrote:
>> On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake<dsd at laptop.org> wrote:
>>> On 5 September 2010 13:57, Christoph Derndorfer
>>> <christoph.derndorfer at gmail.com> wrote:
>>>> I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to
>>>> some discussions started on what changes need to be made to Sugar to
>>>> well in an environment where multiple users will work on the same
>>>> (which is how Peru's next 300,000 XOs will be used:
>>>> Obviously this touches upon a lot of areas from simple naming of the
>>>> machine, over the Journal, backups and probably a whole host of other
>>>> that I haven't though of yet.
>>> When we discussed this while I was in Peru, one requirement they
>>> identified is that the kid would log onto an XO one day and do some
>>> work, and then log onto another XO the following week and continue the
>>> same work.
>>> Assuming this still stands, this strongly calls for a network-based
>>> home directory system with some kind of network login service (but
>>> someone with experience in such areas should comment). This would
>>> require a number of changes at the OS level and server level, but
>>> Sugar would be left untouched, as far as I can think.
>> The standard way of doing this in unix is to use nfs and automount
>> with NIS/LDAP authentication. This would mount the users home
>> directory on login. There's a number of issues that come up with this
>> implementation for the XOs in that wireless would need to connect
>> prior to this and NFS over wifi would be interesting at best due to
>> wifi dropouts. To mitigate that problem you'd probably have to wedge
>> some of the caching filesystems that are being developed to allow the
>> home directory to be cached. Suddenly your getting a very complex
>> solution to fix the problem.
> Yes, this is true. I obviously used wired connections when using LDAP/NFS.
> In a lap with fixed equipment this is an easy setup. For the XOs, I agree
> this could lead to frustration. (even in my case kids very confused because
> someone has pulled the cables)
>> The other possible alternative to this would be to use something like
>> couchdb to store the contents of the journal and associated config
>> files where you can have a local couchdb that replicates to a remote
>> service. This might be the simpler solution but would obviously
>> require development.
> Interesting. A solution where you only need to sync twice (start/stop) might
> be better in the wifi environment.
It is something that I've been meaning of trying to dogfood as a
concept as I think it would be a perfect "cloud" (and yes I frickn
hate the term) storage solution for deployments as it allows you to
change servers, move storage etc without having to reconfigure the
client side. I got as far as setting up the server side of things and
playing around with evolution-couchdb for storing evo contacts but no
further. There's some glib helper files. I was actually hoping to get
more time to play with this more once Fedora 14 / SoaS 4 is out the
door. I have some server resources available to set up the server side
if anyone else is interested as well.
More information about the Devel