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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams > Sent: Monday, September 04, 2006 6:36 AM > To: Martin Langhoff > Cc: [email protected] > 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ć <[EMAIL PROTECTED]> 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 > > [email protected] > > http://mailman.laptop.org/mailman/listinfo/sugar > > _______________________________________________ > Sugar mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/sugar > _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
