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

[Martin Langhoff]

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?

 - 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