Potential TODOs awaiting proposals

This wiki page contains project ideas and resources for students and mentors. Candidates who start a project with skills matching the Requires field will be able to be productive on a given project faster and will probably accomplish more over the course of the project, but project mentors are willing to help you develop those skills (particularly understanding of OpenSRF and Evergreen) if you don't already have them.

Don't feel constrained by this list - if you have other project ideas, feel free to let us know on the mailing list.

• Benefits: Simplifies the install process and improves portability
• Requires: Experience with the GNU Build System
• Explanation: The current install process is a home-grown process using Make and some local install scripts. Replacing this with the GNU build tools will create a more formalized and well-understood install and configure process.

• Benefits: Simplifies install process
• Requires: Understanding of the OpenSRF and Evergreen configuration files
• Explanation: Currently, Evergreen and OpenSRF and their dependencies use a number of configuration files in different locations on the system. This complicates the install process. A single interface for entering settings and having those settings propagate to the various configuration files would improve the install process.

• Benefits: Makes it possible to install OpenSRF and/or Evergreen using the standard package management tools for one or more Linux distributions.
• Requires: The ability to create and test packages in at least one format, or the ability to learn this skill. Learning to create packages will probably take most people a week for the basics, two weeks for more complex packages. Some basic scripting knowledge would help with creating reasonable default configuration files at install time.
• Expalanation: The current install process requires system administrators to install a mix of native system packages, Perl and Python modules, and locally compiled code. Native system package formats such as .rpm (Fedora, Red Hat, SuSE, etc), .deb (Debian, Ubuntu), and ebuilds (Gentoo) removes most of the steps involved in the current install process by ensuring that all package dependencies are installed and by automating much of the system-dependent configuration. To successfully complete this project, you may be required to create system packages for the external dependencies that do not currently have system packages available on a given distribution (for example, Perl and Python modules). This is a good thing - it should offer a gentle introduction to system packaging before tackling OpenSRF as a single package, and you might have the opportunity to become a maintainer of that package for that distribution.

• Benefits: Encourages the spread of Evergreen by broadening the set of operating systems the software will run on.
• Requires: Understanding of the Evergreen installation process and understanding of the development tools available on the destination platform.
• Explanation: Currently, Linux is the only widely deployed operating system in use with Evergreen. We would like to broaden the scope to include FreeBSD, OpenSolaris, and possibly OS X. Though a full port to Windows is outside the scope of this project, porting a subset of the software to Windows given appropriate Windows expertise is also an option.

• Benefits: Allows for easier reporting and troubleshooting
• Requires: Understanding of Evergreen log file output and layout as well as a firm grasp on Unix utilities (e.g. grep, cut, etc.)
• Explanation: Most log parsing is done by hand with ad-hoc scripts. A simple user interface (web or shell-based) to analyze certain transaction and error information in the logs would be a great benefit to administrators who don't wish to build local custom scripts

• Benefits: The system should respond in a more expressive manner to both expected and unexpected events.
• Requires: Understanding of Evergreen components and how they piece together in a running system.
• Explanation: Many of the existing system messages are esoteric in nature and often only provide a small amount of information to administrators. More expressive error handling would allow for faster resolution of bugs and misconfiguration errors.

• Benefits: In particular, automated unit tests will speed up the release process by allowing developers to rely on a known set of existing tests instead of building ad-hoc testing scripts or hand testing.
• Requires: Knowledge of the tested components
• Explanation: There are 2 general types of unit tests for Evergreen: those which test standalone components and those which test published methods. Standalone component tests have a smaller scope and are generally simpler. Published API tests stress various layers of the system and generally need to be able to accommodate a wider range of responses.

• Benefits: Access to an automatically generated set of test data will not only allow for broader, more rigorous testing, it will allow developers to drop and re-create databases for quick development turnaround.
• Requires: Understanding of Evergreen objects and a basic understanding of how objects interact within a relational database.
• Explanation: In some regards, this project could be an extension of the unit testing framework. However, it serves the broader purpose of allowing users to quickly generate data for demos and a common dataset for bug verification.

• Benefits: A common toolkit for institutions migrating from the selected ILS to Evergreen
• Requires: Knowledge of the export processes from the selected ILS, import and policy definition processes for Evergreen.
• Explanation: All ILSs are different in crucial ways with respect to how the store and export bibliographic, transaction, and policy information. Creating a toolkit for a single ILS will not only provide institutions that use that ILS a migration toolkit, it could be used as the basis for a broader set of migration toolkits.

• Benefits: Additional OpenSRF libraries will allow for easier development of ILS plugins for existing and future Ruby/PHP applications. It also opens the door the general OpenSRF development from the Ruby and PHP communities.
• Requires: Understanding of OpenSRF
• Explanation: OpenSRF currently has client libraries in Perl, C, and Python. New libraries generally broaden the scope of OpenSRF, which makes it more applicable in more places, even where Evergreen is not in use.

• Benefits: Current users of a given system will have the ability to migrate to Evergreen without changing patron interfaces
• Requires: Understanding of how to access the needed data in Evergreen as well as how to integrate with the chosen interface.
• Explanation: Third party OPACs including VuFind, Scriblio, Blacklight, etc., offer enhanced search and discovery interfaces for library patrons and typically offer some level of “plug and play” infrastructure. Writing a plugin for a particular interface would allow all Evergreen users to take advantage of the interface.

• Dan Scott: denials at gmail.com
• Sally Murphy: error23 at gmail.com
• Mike Rylander: mrylander at gmail.com
• Bill Erickson: billserickson at gmail.com

• Evergreen Home Page
• Evergreen Repository
• OpenSRF Repository
• Open-ILS-Dev mailing list
• IRC Channel #evergreen at irc.freenode.net
• Evergreen and OpenSRF Downloads
• Mentor How-To

• it's long, so see it here

• Give browsers the ability to use most of the advanced features of OpenSRF, like stateful sessions and streaming responses. Read the proposal here.
• update A Python implementation of the HTTP translator has been developed as well as the OpenSRF Javascript library which takes advantage of the gateway. After the Python gateway is given a good workout, porting it to C will be the next step.

• Request for Comments (RFC) by Dan Scott, 2008/07/01

probably to become the Build/Package/Deploy proposal pending from miker

• “Gentoo ebuild, RPM, and Debian .deb files for installing Evergreen.” – Software Bounties
  • Eric Lesage creates Gentoo ebuild for 1.0.1 (per e-mail to OPEN-ILS-DEV )

• Scratchpad page for notification system discussion.
• Notification subsystem design.
• See Bill's post to OPEN-ILS-DEV)

• Ways to speed up loading of patron records for patrons with hundreds+ fine records/etc. –discussed on OPEN-ILS-DEV

• Anticipated to be long, so Look here!
• mentioned on #OpenILS-Evergreen by Stompro, 7/20/07

• Self serve password reset
• Proposal created 2010-03-28

• Notes on the design and usage of a simple self check client.
• This has been created, was introduced in version 1.2.3 (August 2008). "Web-based Self-Check kiosk mode".
  • Code for this feature - http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/web/opac/extras/selfcheck/
  • Features:
    • Patron Login.
    • Item Checkout.
    • Item Renewal.
    • Receipt Printing.
• To see Web-based Self-Check Kiosk mode in action go to https://demo.gapines.org/opac/en-US/extras/selfcheck/selfcheck.xml. Login with admin, demo123.

• Telephone Notification Discussion