[schooltool-dev] Configuration issues for schools

Sat Feb 7 15:49:23 UTC 2009

Hi Tim,

I'm the project manager for SchoolTool, and I've worked a lot on
interoperability issues between applications used in schools.

Regarding SchoolTool & different platforms, SchoolTool is Python, it
is fairly easily ported to other platforms that run Python.  The only
problem is that we (the core development team) don't have the
expertise to support multiple OS versions, particularly as we have to
focus on finishing our 1.0 release.

I'm a little confused about what you're proposing for configuration.
The standard way to address your use case is via web services or
perhaps LDAP.  There are a few directly relevant existing standards
(SIF...) but none that are widely used, particularly by free software.
or generally appealing.

Actually, at this point, I'd say storing the data you want in LDAP is
probably the approach most likely to work.  The coolest way to do it
would be passing around the relevant data via XMPP.

--Tom

On Sat, Feb 7, 2009 at 8:26 AM, Tim Holy <tim.holy at gmail.com> wrote:
> Hi,
>
> I'm one of the main developers for TuxMath, part of Tux4Kids. This is a
> proposal that I've floated with GCompris, KDE-Edu, and discussed a bit with
> several folks on the #edubuntu IRC. This message is a modified version of a
> message I posted to some of the other lists recently, so if you've seen it
> then you pretty much know the contents of this message.
>
> Over the last year we've begun to think about some issues in making TuxMath
> more useful for schools. As you probably know, TuxMath is an arcade game
> that helps kids practice math facts. Teachers are using it, and several have
> expressed interest in being able to configure, track, and otherwise
> administer classrooms of kids using the program. Adding these capabilities
> will involve much that is TuxMath-specific, but in thinking about the
> problem I've come to the conclusion that this work should probably start
> with a foundation---mostly, a set of standards---that might be used by many
> different free software projects.
>
> To be concrete, here are a few examples of some of the kinds of things we
> might want to support in TuxMath:
>
> 1. Letting teachers set particular lesson files for kids to tackle that day,
> on a class-wide basis but with the ability to further customize lessons for
> particular students or groups of students
>
> 2. Letting teachers see how kids in their own classroom are doing on the
> lessons
>
> 3. Managing "high scores" files by grade or classroom (we don't want 5th
> graders competing against 2nd graders)
>
> The part of this that I think will be easiest to generalize across projects
> is really quite simple: implementing these tasks in a sensible way requires
> a method for expressing relationships in a school. In particular, we need to
> specify the different grades, the different classrooms, and the kids within
> each classroom. This, therefore, is a "system-wide" issue of configuration,
> and not one that teachers or sysadmins will appreciate having to set up 5
> different times in 5 different ways for 5 different free software packages.
> Hence my interest in a set of standards.
>
> I see two main components to this proposal. One is that there needs to be
> software to create and administer these relationships. It's been suggested
> to me that SchoolTool might be appropriate for this purpose. However, please
> note that at Tux4Kids we support Windows & Mac too, so any solution useful
> for us is going to have to be quite general and not Linux/Edubuntu-specific
> (SchoolTool seems to be web-based, but is currently only easy to install on
> Ubuntu?).
>
> The second component would probably be a small library that facilitates the
> ability of individual applications (TuxMath, Tux Paint, GCompris activities,
> etc) to work with this information.
>
> In terms of implementation: one of the challenges is that, at least in the
> US, many schools seem to run without any individual student accounts. In
> other words, all students log in to an account called "Student" that doesn't
> require a password. So we need to set this up in a way that all the users'
> data does not get jumbled together. On the other hand, when schools do set
> up "real" user accounts, we want to make use of that.
>
> I've set up a preliminary architecture for some of this within TuxMath (but
> it will need modifying/generalizing if this is of general interest). For
> better or for worse, I've established a directory hierarchy on the school
> server:
>
> school/
>
> school/Kindergarten/
>
> school/Kindergarten/Mrs. Smith/
>
> school/Kindergarten/Mrs. Smith/Kid A/
>
> school/Kindergarten/Mrs. Smith/Kid B/
>
> school/Kindergarten/Mrs. Smith/Kid C/
>
> ...
>
> school/Kindergarten/Mr. Jones/
>
> school/Kindergarten/Mr. Jones/Kid 1/
>
> school/Kindergarten/Mr. Jones/Kid 2/
>
> ...
>
> school/1st grade/
>
> ...
>
> For schools without real user accounts, these directories serve as a mock
> home directory (without any kind of security) for the kids, where their
> specific data gets saved. In cases where the students do have real home
> directories, the lowest level could of course be symlinks (on Unix systems)
> to their real home directories.
>
> Our tools for administering these directories are quite primitive at the
> moment---a command-line program (NOT teacher-friendly!) called tuxmathadmin.
>
> The advantage of this hierarchy is that it establishes a natural mechanism
> for expressing relationships among the different members of the school, and
> so programs can then find classroom-wide configurations, etc. For example,
> it is natural to "read up" or "read down" when you're looking for
> configuration files. If two of the 4th-grade teachers decide they want their
> kids to have a joint high-scores table, they place a "highscores.txt" file
> in the 4th grade directory. But if another 4th-grade teacher wants her kids
> just to compete among themselves, she can place a highscores.txt file in her
> own directory, and for the kids in her class the application will default to
> using that file.
>
> This is not unrelated to the XDG specification (thanks Jordan for pointing
> me to this), although the various paths might have to be set dynamically in
> cases where there are no real home directories. (For example, we allow
> TuxMath to be configured so that students can select their identity when
> they start the program. Perhaps we might want a common login system that
> then sets up XDG-paths before starting a specific application?)
>
> Is this something of potential common interest? Any other parties that I
> should include in this discussion?
>
> Best wishes,
>
> --Tim
>
> _______________________________________________
> Schooltool-dev mailing list
> Schooltool-dev at schooltool.org
> http://lists.schooltool.org/mailman/listinfo/schooltool-dev
>
>