RFC: Possible Gradebook Architecture

The diagram below shows my proposed design for a gradebook application. The dotted box indicates the scope of the gradebook application.

The different components are as follows:

• EduML or XML Database Processor/Parser - This is where grade information is stored and written to file. This component would be compiled into the gradebook application, but it should be seperated by an API from the rest of the code, so that it can optionally be replaced with other database backends (such as a MySQL client, etc). As I see it now, this component would be responsible for using libxml to read and parse an EduML file containing grade information. The main gradebook application could access or change this information through an API or some sort of XML message processing.
• SIF Agent Library - This is a library (dynamically or statically linked to the gradebook executable) that negotiates a connection with a Zone Integration Server (ZIS). This is part of the Schools Interoperability Framework (SIF) specification. Somebody should write an open-source implementation of this component, for use in many different applications. This would make it very easy for any educational application to add support for SIF to their application. Also, the SIF specification has information on message formatting for gradebook information. I suggest we use that standard.
• The Gradebook Data Processor should consist of an API specifically designed for grades processing. It would take calls from the GUI application and gather data from either the XML database component, or the SIF Agent.
• The Gradebook GUI should be coded as necessary for different platforms or languages. For example, the GUI could be in GTK, web-based, Python, or Windows. It would make use of the platform/toolkit independent components above.

Operating modes

The above design for a gradebook has the advantage that the gradebook could run in a variety of modes (from the same executable), configurable at runtime:

• Standalone Mode - The gradebook data processor would store and retrieve information solely from the XML database. The SIF Agent, although compiled in, would not be used. The single executable could retrieve, restore, and manipulate grade information to/from an EduML file. This mode is useful for people using the gradebook application on their home computers, or in a school without centralized electronic grade storage.
• Client Mode - The gradebook data processor would request and send information through the SIF Agent Library. The user would start the application, type a username and password, and the SIF Agent would authenticate to the ZIS. Then, a user-specified number of records would be fetched from a gradebook server (elsewhere on the LAN) by using the SIF message passing specification. Changes to the grade information would be sent back to the server using the SIF Agent Library. Also, data could be imported/exported to a file using the XML Database built-in to the application.
• Server Mode - The gradebook application would start up without the GUI, and execute as a daemon. It would authenticate itself to the ZIS, and the SIF Agent would take requests from gradebook clients (above) elsewhere on the network. It would use the XML database backend as a means of storing the entire site's grade information.

I think the above architecture provides a high-degree of flexibility in the gradebook application. We can achieve interoperability in a large network in addition to standalone execution. Also, we can support a wide range of interfaces, using a standard API, seperated from any GUI code.