For the past three weeks I've been working on the design of the server-side component of our application, and consulting with Hugo and Eugene on how the client app is going to tie into this. This post focuses on the prospect of integrating our software with existing classroom management software to see how our software would utilize their APIs if we choose to support them, with a specific focus on Moodle. Since Moodle is a modular, plugin-based system, if we choose to integrate our application with theirs we would need to write a plugin composed of PHP, JS, HTML, and CSS.
Moodle seems to have substantial support for everything we need at first glance. The Enrollment and Access APIs provides functions that allow us to pull a list of the students' classes, check if our software is used in these classes, pull lists of the students in each class, and restrict the use of our software to those enrolled in the class through role-based authentication. Being role-based, this also allows the teacher to act as an administrator so that they can a student after attendance polling has closed if a student has forgotten their phone. The Attendance Module provides and modifies a database for storing students' attendance record, with pre-set options to account for being present on time, tardy, absent without an excuse, and absent with an excuse. Students may upload files, which we would use for the secret-sharing based authorization component of our application. Moodle also handles software updates and logging for us.
What's more, since Moodle is open-source, it is installed and managed by each school that uses it. This was an important design consideration-- if each school runs their own copy of our software, as opposed to us running one copy of the server that services every school, we would not need to concern ourselves with operating at a large scale, or with handling potential downtime. Since our plugin would also be open-source, it could be configured by each school to suit their needs. Because Moodle supplies so much support for us, I began to consider developing the entire server-side component of our software as a Moodle plugin, rather than just potentially providing support for it.
However, there were some serious drawbacks to this approach. First, Moodle's documentation is incomplete, and questions are generally handled by the community. While this is a common approach, this made it difficult to find information critical to continuing with this approach-- like whether an additional JSP could be run from inside our plugin to run our facial recognition algorithm, location-checking, random secret generation, and the other components of authentication our application requires. This would mean that Eugene and Hugo's mobile component would need to interface with this JSP, which would then make calls to Moodle, which I felt defeated the purpose of integrating fully with Moodle. Moodle provides a mobile application that users are free to fork and use for their own purposes, but because this is compiled with Phonegap and Hugo and Eugene have decided to work with Qt, this would be inconvenient. Since they are also implementing methods of authentication we felt were outside of the capabilities of Moodle's native interface, like capturing photos or completing lock patterns, I decided against integrating our server-side component fully.
This has been a very roundabout way of saying that I'm not going to do something, but not for naught! We learned a lot in the process of examining Moodle as a host for our server. Moodle provides enough support for integrating core components of our application that I could write a simple helper plugin to integrate our software with Moodle relatively easily. Since this is possible with Moodle, it is likely possible with alternative classroom managers like Canvas as well. Furthermore, the importance of each school running their own copy of our server-side software for scalability and modifiability reasons helped me to realize that developing a desktop application server for professors to run as they take attendance is the most flexible method of implementing our server-side design-- more on this in my next post!
--Nico
No comments:
Post a Comment