Integration with web apps (and Moodle specifically!)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Dan Williams
> Sent: Monday, September 04, 2006 6:36 AM
> To: Martin Langhoff
> Cc: [hidden email]
> 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? <[hidden email]> 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
> > [hidden email]
> > http://mailman.laptop.org/mailman/listinfo/sugar
>
> _______________________________________________
> Sugar mailing list
> [hidden email]
> http://mailman.laptop.org/mailman/listinfo/sugar
>
Reply | Threaded
Open this post in threaded view
|

Integration with web apps (and Moodle specifically!)

Ivan Krstić-2
Krishna Sankar (ksankar) wrote:
> 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

This is a non-problem; we're not using SSL, and our authentication (and
encryption where applicable) are stateless.

--
Ivan Krsti? <[hidden email]> | GPG: 0x147C722D