Re: Seating (was: Re: Gradebook development)

[Justin Bradford <justin@scrtec.org>]

> I may have missed something, but I'm still a bit confused as to why
> you'd want to use XML for something like edulp.  Seems like that would
> complicate things, and I think a simple DBM database suffices pretty
> nicely for this sort of thing.
> ...
> If you REALLY want to get the goal/progress info into other programs,
> either they could be made to read the DBMs or there could be a DBM->XML
> converter (I *think* someone already mentioned that).

The problem with using a DBM interface directly is that we are limited in
future expansion. I think it's pretty clear that we aren't talking about
something like a simple gradebook anymore, but rather a series of
interoperable components, one of which is a gradebook (more like a
gradebook interface to the data, which will very likely contain data the
gradebook doesn't care about).

Now, we could just write these applications without a data storage
abstraction, but I think it's short-sighted. Using DBM directly will very
quickly limit the possibilities of component interaction as well as
data relations (note: I'm not advocating a RDBMS at this point).

However, XML does provide a fairly elegant solution to this problem. We
can rather easily define a file format, which many existing applications
could already read, and the relationship between the objects is fairly
straightforward.
Furthermore, there is software to allow us to read the XML files in a
convenient "tree-menu" view, via DOM interfaces. So an application could
use the DOM interface to read portions of the data without regard to
other, newer additions, or even field extensions to the very data it is
looking at. Basically a component could deal with the data on any level it
wanted to. Someone could write an extremely simple gradebook all the way
up to a district-wide "god" interface where they could personally inspect
the response to question 4 of the last biology exam for all students
with bad attendance in the 8th grade. I don't want to write it, but
technically it would be possible using the same base interface we're
talking about now, which really isn't that much more complex than DBM.

But... the actual low-level storage of this XML data should be a simple
implementation for now, perhaps a DBM, although I suggest we consider
Berkeley DB as it is very powerful, yet small and easy to program for.
Later on, when we're talking about district/state/nation-wide
implementations of the data storage, we can talk about more complex
backends. For instance, Oracle is already planning to implement XML
support via a DOM interface layer, and right now W3 is trying to establish
a stand XML query language.

And finally, with XML when can use a lot of the IMS standards, which was
very widely hyped not too long ago. I made the mistake initially of
thinking a simple gradebook would solve a big problem, but I have since
realized that all of these schools are running or want to move to complex
computer systems to handle this. IMS was trying to define standards for
that, but it seems (to me at least) to have lost its momentum. We could
take up where they left off, and very quickly draw a lot of attention
(along with more developers).

> And do we REALLY want to use GNOME?  That will lock people into using
> the GNOME panel, and now that Qt is open source, it's uncertain that
> GNOME will be the standard.  (Personally, I'm all for both - there needs
> to be good competition, and even Qt's new license is somewhat less than
> 100% ideal.)

All of the UI should be as modular as possible, but not at the expense of
stifling development. I don't think it's unreasonable to start with GTK
(not Gnome-specific, yet, so it will still run under KDE) since the only
substantial UI development experience here seems to be with GTK/Gnome. A
Qt port and tighter integration to their respective desktops should come
at a later point.
Also, for the console interface, I stumbled a description of a library
named newt, which supposedly is a toolkit for curses, but haven't found
the actual library yet. I imagine the output is similar to the text
install programs you see when you install Linux, although that's just a
guess. I'll try to track it down.

Justin Bradford
justin@scrtec.org