Difference between revisions of "TotalRecall Development"
| Line 24: | Line 24: | ||
This is absolutely essential for documentation on the wiki and documentation in build files. | This is absolutely essential for documentation on the wiki and documentation in build files. | ||
| − | == | + | == Minimal dependencies == |
| − | + | Introducing dependencies makes build automation, installation, and maintenance vastly more difficult. It also puts us in the position of relying on third-party open-source projects which may at any moment collapse due to lack of developer time/interest. Native dependencies are the worst, as they must be constantly updated for new operating system versions, changes in system libraries, etc. Plus they can crash the JVM. | |
| − | When dependencies must be introduced they should be pure Java | + | When dependencies must be introduced they should ideally be pure Java, operating in a restricted domain (i.e., not interacting with OS resources which might change over time). Since Java is strongly committed to reverse-compatibility we don't have to worry about the program breaking because of an obscure update to gcc or the release of a new operating system. |
| − | At this point there are only two dependencies that can potentially break | + | At this point there are only two dependencies that can potentially break. |
| + | * The FMOD Sound System. It is used extensively in major games so its stability and quality are assured. Updates are released regularly and their developers are responsive to questions on the FMOD forums. When we switch away from FMOD (to make TotalRecall totally FOSS), it will only involve re-implementing the pluggable sound system (`edu.upenn.psych.memory.precisionplayer` and `edu.upenn.psych.memory.nativestatelessplayer`). | ||
| + | * Java Native Access. This is the only case where we have preferred ease-of-use over our desire not to introduce dependencies. JNA is ''much'' easier to use than JNI and requires no bioler-plate code. It is also a high-quality library unlikely to break in the foreseeable future. If it does we can fall back on JNI. | ||
== Minimum developer overhead == | == Minimum developer overhead == | ||
Revision as of 18:12, 29 March 2010
Penn TotalRecall Development
)>><<TableOfContents(3)>>
Open-source software is a collaborative effort. PLEASE inform us if anything on this page is incorrect or out of date.
License
TotalRecall is free and open-source software, released under the GNU General Public License, version 3. We encourage other groups to modify and improve the program. Please drop us a line if you're interested in developing TotalRecall or borrowing its code.
[Please note that at present we have one non-free dependency, so the resulting binaries are not fully free and open source. We are working to produce a completely free and open source version in the near future.]
User interface goals
Under construction.
Development goals
Up-to-date documentation
Keeping documentation current with the code base is an ongoing challenge. If you change the code, please make sure you are changing the documentation and propagating those changes to any other documentation that references it.
This is absolutely essential for documentation on the wiki and documentation in build files.
Minimal dependencies
Introducing dependencies makes build automation, installation, and maintenance vastly more difficult. It also puts us in the position of relying on third-party open-source projects which may at any moment collapse due to lack of developer time/interest. Native dependencies are the worst, as they must be constantly updated for new operating system versions, changes in system libraries, etc. Plus they can crash the JVM.
When dependencies must be introduced they should ideally be pure Java, operating in a restricted domain (i.e., not interacting with OS resources which might change over time). Since Java is strongly committed to reverse-compatibility we don't have to worry about the program breaking because of an obscure update to gcc or the release of a new operating system.
At this point there are only two dependencies that can potentially break.
- The FMOD Sound System. It is used extensively in major games so its stability and quality are assured. Updates are released regularly and their developers are responsive to questions on the FMOD forums. When we switch away from FMOD (to make TotalRecall totally FOSS), it will only involve re-implementing the pluggable sound system (`edu.upenn.psych.memory.precisionplayer` and `edu.upenn.psych.memory.nativestatelessplayer`).
- Java Native Access. This is the only case where we have preferred ease-of-use over our desire not to introduce dependencies. JNA is much easier to use than JNI and requires no bioler-plate code. It is also a high-quality library unlikely to break in the foreseeable future. If it does we can fall back on JNI.
Minimum developer overhead
Please be mindful that future developers and maintainers may not have the same skill set as you. So with future maintainers in mind it's best to minimize the number of exotic technologies needed to build or develop TotalRecall. At this point some knowledge of Java, C, Java2D/Swing, Ant, and GNU Make is already needed. Let's keep this list short by not needlessly adding C++, OpenGL, <your-favorite-technology>, etc.
Build automation
A brief look at our Ant build.xml reveals that we are not aiming for "zero dependencies" in our build toolchain. The build chain is designed to make it quick and easy to build/package/release TotalRecall for the many operating systems and architectures we support. While the basic build process (i.e., what's needed to get the program running on your computer) should remain simple, the full build system (e.g., creating installers, transferring to download site, etc.) can introduce dependencies and developer overhead as needed.
Dependencies and borrowed code
- FMOD Sound System, copyright © Firelight Technologies Pty, Ltd., 1994-2010. (FMOD non-commercial license).
- Java Native Access for binding the audio system to the JVM.
- OpenMary TTS's signal processing library (BSD-like).
- Drag and drop support thanks to FileDrop (Public Domain).
- Apple Java Extensions wrapper (BSD-like, but no source provided).
Supported configurations
| Operating System | Java versions |
| Mac OS 10.6 (32/64-bit) | Java 6 |
| Mac OS 10.5 (32/64-bit) | Java 5, 6 |
| K/Ubuntu Linux 10.11 (32/64-bit) | Java 6 |
| Windows 7 (32/64-bit) | Java 6 |
| Windows Vista (32/64-bit) | Java 5, 6 |
| Windows XP (32-bit) | Java 5, 6 |
Note: Mac PowerPC is not officially supported, but the program is known to work on it.
