[sugar] Integration with web apps (and Moodle specifically!)

[Krishna Sankar ksankar]

Yep, we need to make sure we do not go overboard with AAA, identity and similar primitives. This was my point about a stateless machine (which as Dan correctly points out is more peer-to-peer than a client-server) that has the demeanor of a toy/book than an enterprise-like machine. 

Moreover identity et al is still a challenge, even in very controlled corporate environments and it would be more challenging for us.

I am not saying we shouldn't have class room interfaces, but want to make sure we make the right assumptions and embed the primitives that reflect the domain ... I would prefer a light-weight trust fabric with minimum touch points ... 

Also be very careful about the message exchanges - things which are very easy in normal environments can be very energy draining in a mesh environment ... Just think of an SSL exchange thru 5 meshed systems (in the most degenerated case, they all could be in a linear mesh and the first -or last depending on how you look at it-  one in the chain has to route all the messages ;o() 

Cheers
<k/> 


> -----Original Message-----
> From: sugar-bounces at laptop.org 
> [mailto:sugar-bounces at laptop.org] On Behalf Of Dan Williams
> Sent: Monday, September 04, 2006 6:36 AM
> To: Martin Langhoff
> Cc: sugar at laptop.org
> Subject: Re: [sugar] Integration with web apps (and Moodle 
> specifically!)
> 
> On Sun, 2006-09-03 at 17:15 +1200, Martin Langhoff wrote:
> > On 9/3/06, Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> wrote:
> > > Martin Langhoff wrote:
> > > > One is the API to talk to sugar and other services 
> (identity, group mgmt).
> > >
> > > D-Bus.
> > 
> > That's IPC AFAIK... from the D-Bus Tutorial it's for
> > 
> > * Communication between desktop applications in the same desktop 
> > session; to allow integration of the desktop session as a 
> whole, and 
> > address issues of process lifecycle (when do desktop 
> components start 
> > and stop running).
> > 
> > * Communication between the desktop session and the 
> operating system, 
> > where the operating system would typically include the 
> kernel and any 
> > system daemons or processes.
> > 
> > The kind of scenario I am considering is with Moodle on a 
> > school/teacher server
> > 
> >  - Can Moodle ask what user accts are valid in this 
> (school) context? How?
> > 
> >  - Can Moodle ask what groups/courses are valid in this context and 
> > who's in them? How?
> 
> That's almost completely outside the domain we're working in. 
>  We're providing a framework for that sort of collaboration, 
> but we're _certainly_ not developing a school system here, 
> for the huge reason
> that:
> 
> - OLPC is targetted at a large number of disparate school 
> environments.
> We certainly cannot be sure of how classes are run, and how 
> schools are run.  We can't, shouldn't, and won't impose a 
> western-style class structure and school organization 
> structure with this project.
> 
> Some schools are 30 kids with all the grades together taught 
> by the same teacher outside.  That doesn't lend itself 
> towards a centralized structure with a school server.  Others 
> are much more centralized with defined schedules, 
> grades/classes, classrooms, etc.
> 
> These things are hugely country-defined and the same solution 
> that fits eg urban Brazil wouldn't even necessarily fit rural 
> Brazil.  Therefore, we're leaving any sort of this heavy 
> school administration infrastructure up to countries and 
> other projects themselves.
> 
> We may provide a concept of "class", in the sense of a loose 
> group of children who may be similar skill level and be 
> together during the day, but there aren't any promises.
> 
> Furthermore, the laptop has to be useful in a small system 
> without dedicated application server.  So it is much more of 
> a peer-to-peer model where we can't guarantee access to a 
> school server.  So you can't rely on being able to verify 
> people by accessing the server before talking to them.  What 
> happens when the child takes the laptop home?
> Still has to be able to talk to people around even though the 
> school isn't necessarily contactable.
> 
> Dan
> 
> >  - When a user connects via HTTP is there a way to authenticate the 
> > user transparently? How?
> > 
> >  - Are there school administration tools Moodle should 
> communicate with?
> > 
> > > > The other is deployment framework for the school or teacher 
> > > > machine, which is probably more powerful, or (more importantly) 
> > > > just dedicated to being a server.
> > >
> > > I'm not sure I understand what you mean by 'deployment 
> framework'. 
> > > Can you elaborate?
> > 
> > Will those machines actually have RPM/Yum/APT? AFAICS, the OLPC OS 
> > image does away with the overhead of carrying a package manager...
> > 
> > > > But this is a for a client-server scenario. Clients are using 
> > > > Sugar+Gecko I assume
> > >
> > > Right. Sugar uses XULRunner, which embeds Gecko.
> > >
> > > > so I will be focusing on trimming HTML to see if we can lower 
> > > > in-memory footprint of rendered pages inside Gecko.
> > >
> > > In general, unless you have outrageously bad markup that e.g. 
> > > contains all styling inline, your time is probably better 
> spent just 
> > > making sure you don't output any very long pages, instead 
> offering 
> > > pagination wherever possible.
> > 
> > Is that based on actual benchmarks? My experience is that some 
> > webpages, while not being significantly larger than others can take 
> > many times as much RAM. The approach I'd like to take is to profile 
> > them and go after the worst offenders and/or at least nag 
> the relevant 
> > Moodle module maintainers ;-)
> > 
> > cheers,
> > 
> > 
> > 
> > martin
> > _______________________________________________
> > Sugar mailing list
> > Sugar at laptop.org
> > http://mailman.laptop.org/mailman/listinfo/sugar
> 
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar
>