[Sugar-devel] Enhancing Sugar to support multiple users

[pbrobinson at gmail.com]

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:
>>>>
>>>> Hi,
>>>>
>>>> I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to
>>>> get
>>>> some discussions started on what changes need to be made to Sugar to
>>>> work
>>>> well in an environment where multiple users will work on the same
>>>> machine
>>>> (which is how Peru's next 300,000 XOs will be used:
>>>>
>>>> http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html).
>>>>
>>>> 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
>>>> issues
>>>> 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.
>>
>> Peter
>
> 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.

Peter