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()
> -----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
> 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
> - OLPC is targetted at a large number of disparate school
> 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.
> > - 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
> > > 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
> > > 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]
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
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
|Free forum by Nabble||Edit this page|