Code Philosophy
SEE https://github.com/ampache/ampache/blob/develop/CONTRIBUTING.md
This data is way out of date so the contributing file will be updated.
This document is meant to give potential developers or anyone who would like to see a feature added to Ampache an idea of the current focus, and goals of the project. This should allow the above mentioned individuals to better frame their requests, patches to meet the philosophy of the project.
Pour l'Amour de la Musique / For the Love of Music
- Application Security
- Speed
- Accessibility
- Compatibility
The objective of Ampache is to organize and stream your music collection anywhere. Ampache should not require that your music is in any normalized file structure and should provide tools to improve the organization of your music. Ampache should be secure enough so that you feel comfortable that nobody can download your music without your permission while at the same time providing ease of use for authentication free environments such as an internal lan. In order to avoid bloat Ampache should not include anything that does not contribute to the selection, organization or playback of your personal music collection.
Many PHP Applications developed today are plagued by SQL Injection vulnerabilities, cross-site scripting attacks and many other security flaws. Although there is no way to make any program perfect Ampache is designed to whenever possible force good security by default. Often Ampache will sacrifice ease of use for security. For example the Ampache installation assumes that you have both a root level account for inserting the database, and a user level account for using it and will not allow you to have an empty password in either.
All new Code developed for Ampache should maintain this mindset, security first. User input is never to be trusted, and anything not provided by the application it's self is considered to be tainted and should be treated as such. Any new features like XML-RPC which are inherently insecure should require extra security measures be turned on in order for them to function.
Ampache takes pride in the fact that it is relatively fast. This is in part due to its native MySQL calls along with conscientious programming. Any additional features that might slow down Ampache should be able to be turned off so they don't make any noticeable impact on performance. Some features might be outright rejected if they impact performance too greatly; such as using Adodb which can incur up to a 27% performance hit on SQL calls.
Whenever possible, steps should be taken to increase the speed of the existing Ampache code. Some ways of speeding up Ampache may include, simplifying or optimizing SQL calls, reducing code overhead by improving algorithms or using some other form of mojo.
Ampache strives to be Accessible to all web browsers, operating systems, languages and species. When possible all features of Ampache should work on all web browsers operating systems and in all languages. Naturally some features such as album art will not work on a text based browser and are exempt.
Ampache makes every effort to support all common music types and platforms. No code should be added that purposefully excludes a single music type or requires strict compliance to standards. For example Ampache should to the best of it's ability deal with incomplete or damaged tag information in audio files and or damaged or incorrect images. Ampache should also make every attempt to deal with every possible PHP configuration which at least meets the minimum requirement. No assumption should be made of a specific memory, execution time or session handler type being set by the users. When possible everything should be set by the Ampache it's self.